Hi @joacim-svensson_8194 ,

A vulnerability is tied to a vulnerability source (you can see the source name on the vulnerability page), and a vulnerability source is tied to one or more feeds.

So when you create a second vulnerability source, then you'll see two sets of vulnerabilities and be able to assess each vulnerability differently.

Cheers,
Steve

Hi @cshipley_6136 ,

Based on this, it looks like there are some network problems between ProGet and your SQL Server:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections.

It's really easy to reproduce this error (just make a typo in the server name) but when it's intermittently happening, it means the problem is happening within the network, between the two servers.

Unfortunately you won't be able to find any useful information on the SQL Server side, since the connection cannot be established. And the same is true on the ProGet side, for the same reason.

This is definitely something to bring up with your Network/Operations team. It could be anything from DNS issues to router configuration to a bad/failing switch.

Best,
Steve

Hi @cshipley_6136

Can you give more details about the error messages you were seeing? You mention it's a login error, like a bad SQL password or account or something?

The health check (/health) runs the Feeds_GetFeeds procedure... so it should have given a 500 error / crashed if the database couldn't be connected.

We'll try to reproduce the failed failure, and get it fixed asap.

Cheers,
Steve

Hi @tyler-engelhardt_8011 ,

I looked at the docs briefly, but I'm really not familiar enough Ansible to know what could be the issue, or how they try to run Chocolatey behind-the-scenes. It's most certainly a configuration issue in your Ansible script though.

So far as I can tell, Chocolatey is not installed on the server, so Ansible is trying to look for a file called install.ps1 on the ProGet server (which obviously wouldn't be there) to install Chocolatey. That file is located here: https://community.chocolatey.org/install.ps1

I would try contacting the Ansiblesupport team or play around with the parameters like bootstrap_script. Please let us know what you find.

Cheers,
Steve

Hi @lm ,

We don't track that information on the package history page at this time; you'll have to find it under Admin > Events.

It's definitely something we can consider with/after v2023, once we've centralized information about packages in the database. I'll make a note of that!

Cheers,
Steve

Hi @lm,

Unfortunately it's not trivial to get a reliable URL for the package within the webhook module/code now, so it's not something that's easy to add on our end. The URL you have works for NuGet, but for other formats (Ruby, Debian, etc.) you need to include more information I believe.

After v2023, where we plan to centralize a lot of this, it might be easier to reconsider this. But for now, what you have is the best/easiest solution.

Cheers,
Steve

Hi @lm ,

Can you give a little more insight into the use case for this? Why would you want to proxy these symbols?

There doesn't seem to be much gained by caching/proxying symbols, since the symbols basically contain a pointer to a public GitHub repository (or a public source server with the older format of PDB), which wouldn't be practical to cache/proxy.

Cheers,
Steve

Hi @lm ,

We've considered this over the years, but realized it'd be more engineering effort that just changing cookie duration; we'd want to track login sessions on the server side, allow them to be invalidated, etc.

It's possible, but it seems the "Remember me" function on most services (GitLab, etc.) seems to be very forgetful anyways (for security purposes), and with Integrated Windows Authentication and browsers managing passwords, it seems not so valuable for the effort.

Cheers,

Steve

Hi @paul_6112,

There is no built-in blocking to BuildMaster/Inedo agent, and each execution (deployment) uses a separate temporary directory, so there's no conflict on "our" side of things.

However, if you wanted blocking of sorts, you could create resource pools if you'd like to do that, or use lock statements.

Cheers,
Steve

Hi Scott,

Glad you could resolve it; definitely a strange error, I would have expected a better one than just 500.30.

How did you install ProGet? Using the Inedo Hub?

"The Module DLL C:\Windows\system32\inetsrv\aspnetcore.dll failed to load. The data is the error" -- this sounds like a sort of internal error, caused by the .NET6 hosting bundle not being installed, or not installed properly.

https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/hosting-bundle

The Inedo Hub will install this when you install/upgrade to v2022.

Thanks,
Steve

Hi @mcascone,

I'm not sure if we'll be able to help too much with analyzing your Wireshark traffic to be honest; we're not really experts at debugging TCP/SSL-level things, and we'd probably need to spend a half a day re-learning how it all works before we could tell you what it might even be.

There's likely some obscure Windows setting or some network setting that your network ops team would be much more familiar with. They're a lot more familiar than we are :)

As for the upack bug, I just posted an issue now -- https://github.com/Inedo/upack/issues/72

We don't have a regular release schedule for upack, so I can't give an ETA.... hopefully it's relatively easy to work-around for the timebeing?

Cheers,
Steve

Hi @mcascone ,

Just looking at the code real quick, I suspect we have a bug where it writes out the wrong files name for the new package:
https://github.com/Inedo/upack/blob/master/src/upack/Repack.cs#L120

That's probably an easy fix, which we can do as part of this Q&A item. I'll wait to hear back about this one.

As for the error, "The underlying connection was closed: An unexpected error occurred on a send.", that sounds like it's HTTPS related. Could you attach Fiddler, or something like that, to find out what's happening under the hood? We may be able to error message to better report it if so.

Cheers,
Steve

Hi @fkarlsson_2176 ,

Linux servers need to be restarted?

Yes - it's a bit tricky to do the reboot in OtterScript, due to the connection being lost like that. That operation has some special handling for that.

Anyways - we'll add support for this via BM-3793 -- I think that never made its way over from Otter. We hope to ship that in the October 21 maintenance release, but it might be delayed if it's complex or sisues during testing.

Cheers,
Steve

@jim-borden_4965 that doesn't sound right; can you create a new forum post (don't want to clutter this anymore) with some more details/etc, and then we can reply/investigate. Thanks

Hi @scusson_9923, this was implemented in ProGet 2022 :)

Hi @karsten-meichsner_9039,

I haven't seen that error before, but based on the text ("ProxyAuthenticationRequired for layer"), I think that Clair is trying to download an external layer?

Some container image manifests (especially Windows, but not entirely) will point to a URL outside of the registry. This is often done for licensing reasons. What this means is that, Clair (or the docker client) downloads the layers from a url instead of ProGet.

I'm not familiar enough with container scanners (Clair) to know how they search for vulnerabilities; I believe it's done by looking at the packages installed on the system. Log4j is not a package installed on the system (I think), but a library used in some applications.

Cheers,
Steve

Hi @gurdip-sira_1271,

Just to let you know, Otter v2022 has been released; from here it'd be best to start a new thread if you have a specific issue -- we'll be happy to help!

Steve

@nkumari_3548 you'll likely want to check with your network team for help on this one

ProGet is a standard web application, and will listen for all traffic on the port you've configured. If you want to access ProGet with proget.my-company.corp, then you'll need to have someone configure appropriate domain/DNS records, etc. You may also need firewall settings, and a certificate for HTTPS.

https://proget.inedo.com/ is our public instance of ProGet. It's not intended for direct access by users, but by tools like docker or Inedo Hub. You can't login to it.

@sebastian that's awesome, great you could figure it out!

The Package_Versions field is supposed to be some kind of range specifier (e.g. something like [3.4.4-3.4.4.8), but I don't know format offhand). However, we've also never seen it in the wild in any dataset. It's always just a CSV of versions.

Regarding licensing, that information is not really in the database. It's parsed from the manifest file (e.g. .nuspec) in the front-end. That file is stored in database, but it's practical to use in SQL. We talked about building a kind of job that would normalize that into a PackageLicenses table, and then allow custom reporting (or show how a consumer is using it).

At some point, we'd love to get a copy of your data (database backup if possible) so we can see some real-world consumers/consumption and build some pages from it. We do have some sort of idea in PRoGet how to make this look/work better, but seeing real data would be helpful. That development won't start until Q2, so maybe we'll reach out in a month or so and ask :)

@sebastian great, let us know what you find!

When it comes to reporting/reading data, no problem directly querying the tables. We definitely support that, and some folks have quite advanced reports that tie together various systems.

I'd just go directly to SQL Server for that , and do SELECT on the appropriate views/tables. Let us know what questions / issues you have!