Posts made by harald.somnes.hanssen_2204

There is a lightweight standard for bom called cyclonedx though (https://cyclonedx.org/).
Cyclonedx can be output as either xml or json, which can be consumed in an application such as dependency-track. The problem though, is that dependency-track consumes the bom file and does not keep it.

Of course, it's possible to Asset Directory could be used as a bom repository, though pushing files to a git repository might be better in that regard, since it's easier to download the whole repo and compare files.

Just curious if Inedo has any thoughts about sboms (software bill of materials) and how they can be stored outside of a service which tracks dependencies.

I'm starting to see a need for a service that makes it easy to find a sbom from somewhere, similar to how a package repository works.

Case:
You have created a new application or updated the application, and you've created a bom file.
The bom file isn't necessarily pushed automatically to a service (such as dependency-track), but put in a repository which then can be pulled when the application is finally pushed to QA or Production.

@Stephen-Schaff We're also considering locking down nuget.org, so the more info we have in ProGet, the better.

Is it possible to add a filter which hides packages that are less than x days old in the connector settings? This is specifically packages that are pulled through external package repositories.

The date could be published date noted in the package.

From a security point of view, it would be ideal that a package gets a few days or a week, to see if there are bugs or updates during that time period before actually pushing the package into the feed via the connector.

Why: For instance NPM
Recently the UA-parser-js was discovered to have malicious code and it took 4 days(?)
https://snyk.io/vuln/npm:ua-parser-js

After recent events in the NPM community regarding ua-parser-js, makes me concerned having unmonitored package sources in our enviroment. Doesn't seem like there are package repositories available for flutter quite yet, that mitigates that concern.

What does the roadmap look like now?

Seems like flutter is gaining more traction and is the preferred way to create mobile applications quickly.

Is it possible for Inedo to consider having the option of a test upgrade license for ProGet?
I've read the agreement, but I'm wondering if there's a possibility to figure out something that would benefit both Inedo and the customers.

In my case after being stuck with a maven issue, where the error was an edge case and took a lot of time for Inedo to figure out, I had to go back and forth on ProGet versions in my production environment to recreate the case. I also timed the up and downgrades within lunchbrakes and activity in the company. This is probably not ideal, though Inedo Hub made the up and downgrade easy by clicking a few buttons on the server.

Some would argue that the ProGet Free edition might be a good option to use during a test period. But since it does not come with Active Directory integration, that creates an complication where the AD integration might not work after an upgrade (which has happened a few times in the past).

I'm not looking for example a complete ProGet, but something that lets the customer

• have a few feeds and connectors for a given type to check if an upgrade affects the feeds in any way
  • meaning - severly limited
• check if the application comes up at all
• debug ProGet without halting Production

In actuality the ProGet version I'm talking about, would be even more limited than ProGet Free since it cannot be used for anything else but test the upgrade.

With the amount of feed types Inedo offers, ProGet is bound to have one or two bugs that is missed in QA.

That's great :)
"Feed Usage Instructions" or "Feed Usage Guide"?
"Getting started using the feed"?
I'm wondering though; should the help button be separate from the feed options? It's not always easy for end users to spot that the button is a drop down. Actually I gotten a lot of questions about features that were hidden in the dropdown.

I don't usually experience that people ask for help options in software, instead they ask the person who knows the software best. Especially if there's nothing leading them in any direction. People don't look for a help option, they just assume it should be there (from what I've observed).

Having said that, a "help me" option makes it easier to direct the end users attention. Right now, I'm writing "help me" guides for all sorts of feeds, but the guides are all in confluence, so the end user will need to know about the link to the information. I want the users to be as independent as possible, meaning that the tool guides the users as much as possible without having to ask a colleague. Especially, if everything is setup correctly on the software side (ie ProGet).

Customizing the help page could be useful, if there are extra steps that needs be considered. F.ex. we have an internal proxy in our network, that may make our package repository unresponsive. So being able to add info about the setup for the proxy may be helpful.

Also noted that the "description" field for a given field, isn't used for anything (ProGet 5.3.33)? It does not show for any sort of user, which is sort of sad, since I want to inform the user the purpose of the feed. Some users have started consuming an internal library feed (no connectors, just packages), instead of the feed consisting of internal and external connectors.

At the very least, a bulk operation would help.

@stevedennis said in Feature Request - ProGet - Update vulnerability list if a package is not available in any feed:

I did just want to confirm this bit...

Manually by version, where the version is either removed entirely or unlisted .. very ineffective.

Are you referring to deleting/removing vulnerabilities, or the packages themselves? Are you using "retention rules" to clean-up the old chocolatey packages?
Basically the feature idea I'm thinking essentially a checkbox on the Retention Rules, where it deletes the vulnerabilities when the package is deleted, if no other packages are using it. That seems like the easiest and most explicit way to manage going forward

I'm referring to the deleting/removing vulnerabilities.
Yes, we are using retention rules to remove old chocolatey packages. We currently allow 10 versions of each package, anything older gets deleted.

A checkbox sounds like a good idea.

How do you remove internalized chocolatey packages? Is this using the Package Retention Rules feature? Maybe it would make sense to add a deletion as part of this process.

Manually by version, where the version is either removed entirely or unlisted .. very ineffective.
Having the option to actually consider unlist or delete as part of the process would be more helpful than the current assessment (which lasts for 90 days ..)

How many excess/outdated vulnerabilities do you have now? Handful? Dozens? Hundreds?

Firefox has so many that it's hilarious
This is the currenty view in our Proget Instance:

If a package is listed with vulnerabilities and the package is removed from all feeds. The vulnerability is still listed.

Suggestion: have a scheduled task that refresh the vulnerability list with packages that are available from ProGet, not those that are unlisted or deleted entirely.

Cases:
We remove internalized chocolatey packages that are older than 10 versions. It doesn't make sense that we have to assess those packages eventhough they are removed. Earlier versions of Firefox (around version ~80 and downwards) have a multitude of vulnerabilities that fills the Vulnerabilities view, they persist even after the packages aren't available on the server.

We have the same need for an internal Flutter repository.

The reasons are

• We have an internal proxy - which means the build servers has to be configured with proxy settings. With an internal repository we avoid it
• Better grasp of which packages are deemed insecure
• Pulling packages directly from the web without any sort of evaluation is not ideal securitywise.
• Even if OSS Index does not support Flutter packages today, it might be come a thing in the future.
• Caching packages elevate traffic to providers.

What about the end user?
In many cases it's not obvious for the end user how the feed should be configured on the client side.

Things the user might be wondering about: Does the feed require an api key or a combination of user:password as an apikey?

As an end user, I cannot see anything that points me in any sort of direction of configuring the feed on the client side.
I see the API endpoint Url, I can browse the packages in the feed I'm allowed to see, but everything else requires a knowledge of how the ProGet works.

What I propose is:
Next to the Manage Feed button, there's a "Set Me Up" or "Client configuration" button which guides the user to the correct config of the feed. Or put the configuration help next to the "Manage feed" button somewhere.

Setting up a nuget feed through Visual Studio has in many cases been a pain, compared to use nuget.commandline. Since Visual Studio prefers to the credentials manager for credentials. While nuget.commandline inserts both feed and credentials into the nuget.config file for the user.

The todo tooltip was the first thing I turned off:

Having huge boxes trying to tell you something while you're not looking for it, might be the first thing an admin turns off.

We don't use windows authentication to log in, because that would make it hard to log in with different users in the same windows session.

The use case is as follows:

Setting up feeds for IDEs on developer machines and build servers with username and api key, instead of username and password
Having a button which suggests the approach for a given type of feed, will make it easier to succeed setting up a feed on a remote client at any given knowledge level at the enduser side.
The button can be considered to be a call to action for the end user.

How it works now, if the end point for a given nuget repository is not known:
Go to ProGet
Locate repository
Copy the url from the api endpoint url field
Go to nuget docs for nuget.commandline or dotnet.cli
Find the section about adding source
Try to figure out if you need to add a password or an api key
Try to set up an api key from the administration view
Create the nuget commandline to add source with username and password (unsafe) / apikey (safe)
Run the commandline locally on a dev machine and see if it works

How it could work with a button, if the endpoint for a given nuget repository is not known
Go to ProGet
Locate the repository
Click the button, ProGet will create a commandline with an api key
Paste the commandline produced in ProGet to a developer machine

Is it possible to have a button on the ProGet website which can create the commandline to add a repository with an apikey for the logged in user?

F.ex. a nuget feed:

nuget sources add -Name <repositoryname> -Source <url to proget and repository> -username <currently logged in user in ProGet> -password <apiKey from ProGet>

JFrogs Artifactory has had this feature to create configuration setups for a while and it's pretty nifty.

@rhessinger Figured it was something like that, but it wasn't really clear.

Figured it out.
It was the option whether it was Free/Open or Private/Internal that made a difference.
As soon as I set the feed to Private, then the list of packages were displayed.

The Chocolatey feed has 6 packages available

However, the feed seems empty

If there is a guide somewhere, how to traverse and push, then sure. But I haven’t found such a thing.

The only thing I’ve heard from other forums is a question: Is ProGet really a good option for Maven?

As with you, I don’t have much knowledge about maven. Working on it though, but as you’ve mentioned, it’s just weird.

However, I’ve got a hunch it’s sort of like a file repository. Where everything connected to a version is put into a folder and pom. Unlike nuget where a package contains a version and lists of dependencies in the nuspec file. I don’t really know, but that’s my impression of maven vs nuget.

I’d suggest you guys should invest time in the types of products your customer might come from. Don’t underestimate the power of a guide, easy transitions and quality checks to reassure customers. Look at Octopus Deploy how much effort they do, I rarely have issues figuring out how to do stuff with their features.

By the way, I appreciate that ProGet Free has enough features to let me do a POC. Only Nexus Sonar is at the same level as ProGet free when it comes to the amount of repository support.

According to

https://docs.inedo.com/docs/proget/feeds/nuget

it is possible to use
https://«proget-server»/api/v2/package/«feed-name»/«packageName»/«versionNumber[optional]»

However ProGet does not seem to acknowledge any feed with
http://serverurl>/api/v2/package/<myfeedname>/<packagename>

Is this feature gone from ProGet 5.3?

We have a couple of huge Maven repositories in Artifactory, which I'm trying to figure out how to transfer to ProGet.

Since it's not possible to do a bulk import or similar, I'm wondering what sort of method should be used.

Hi.

I'm wondering if it's possible to log the IP or hostname of the machine when an Error Message of type 401 error is created?

I have a case where a user or a scheduled task is constantly trying to access a certain feed, but since the user is anonymous, there is no way of figuring out where the request comes from.

Product: ProGet
Version: 5.0.10

F.ex
Person A needs view and download access to two feeds or more,
Person B needs manage access to four feeds,
Person C administers six feeds, but not all feeds
Person D, E, F, G needs the same rights as person A.
Person H needs same rights as C.
And so forth.

The security would be a lot more manageable if ProGet defines teams, which you can either add a AD user or AD group. In the team, you define which feeds are accessible with a specific security level.

We don't have access to add or remove AD users in a AD group, that's something a third party does for us + it makes the management really annyoing.