Posts made by atripp

Hi @zs-dahe ,

Thanks for clarifying, that makes sense; that's not really the use case we intended for asset directory versioning, it was mostly a simple way for asset-directory end-users (i.e. generally not ProGet admins) to fix the occasional delete/accident. It's redundant with back-up, but the idea was that it would save administrator time at the cost of a little disk space.

Since it'd be such a large change on our end to rewrite this, it'd be best to wait until there's more demand.

Perhaps you could just not use asset versioning , and allow your backup server to handle this? Typically back-up tools will already retain a certain number of past versions of files.

Cheers,
Alana

Hi @arlymac_7956

This error will occur when the database and installed product are not the same version. This is a rare scenario, and will happen if you make certain changes to the IIS/Service configuration on a server.

For example, if you were to copy the application folder (e.g. c:\Program Files\ProGet) to a new location, and then run the web application from that location, then it wouldn't be updated when you update ProGet.

If you can't figure how it's happening, I would recommend uninstalling. Then try to delete any remaining configuration like services/IIS. Don't delete the database or the packages of course.

Then when you reinstall, just point to the database and it shoudl work fine again.

Best,
Alana

Hi @scott-wright_8356 ,

To set a package to blocked, first pull the package to ProGet, then use "Set Package Status". You can then set "Download allowed:" option.

do you intend to allow users to modify the vulnerability database

We do not intend to allow users to modify the database. There are several reasons for this.

1. We could not come up with a suitable use case considering the alternative options
2. It's not something other security products allow
3. It creates a usage/support problem because it's easy to "forget" that the data was edited and then there's a strange behavior

Cheers,
Alana

Hi @zs-dahe ,

Thanks for pointing this out - I don't think anyone's noticed this before

You are correct, this is not supported - and actually it's never been supported. I just updated the documentation to clarify this.

Looking at the code, this wouldn't be trivial to implement and would introduce a fair amount of risk. We would basically have to rewrite retention rules for asset directories, which is a bit scary. I suspect that's why it was never implemented in the first place, and we just didn't update the docs (which we try to write before/during feature development).

Asset versioning is really just intended to undo an accidental change/deletion and download an old version of a file. We don't envision lots of versions of files, so it doesn't seem like a needed feature -- would be interested tot learn how you intend to use it?

Best,
Alana

Hi @v-makkenze_6348 ,

We have a copy of your database, and we can look to reproduce this. Offhand, I believe it's a result of "bad data" (duplicate packages) that are in your database, and it's the same issue behind here: https://forums.inedo.com/post/15730

We need to write a clean-up script for that, but in the meantime you'll want to rollback.

The version should show up in the drop down, but if it's not, maybe try downloading the Inedo Hub again: https://my.inedo.com/downloads

And if that's still not working, maybe try downloading the Offline Installer for the latest 2023.x version.

Cheers,
Alana

Hi @scott-wright_8356,

Are you suggesting that the version range we have logged (≥ 4.20.0-rc & < 4.20.2) is incorrect? That particular vulnerability is sourced from a GitHub advisory:
https://github.com/advisories/GHSA-6r78-m64m-qwcf

If that's the case, it'd be best to report that to the source so that 40.20.2 and 4.20.69 also show up? It should then be reflected in our database quickly shortly after that.

Otherwise, there are a couple options you can use to block unwanted packages:

• set a package's status to Blocked (after downloading it) to manually prevent a download of a package
• use a connector filter to prevent all versions of that package, then manually add the ones you permit

We may add other options down the line, but we intend to allow users to modify the vulnerability database (PGVD) since that it synced from security.inedo.com.

Cheers,
Alana

Thanks @philippe-camelio_3885!

Should we update our docs to reflect this? Does this basically only apply to Ubuntu 22.04+?

Currently, the instruction we have uses apt-key add instead:
https://docs.inedo.com/docs/proget-feeds-debian

Thanks,
Alana

Hi @rick-kramer_9238,

I'm really not sure what the underlying issue is or how to troubleshoot :(

NuGet dependency resolution is really complicated, and what you're saying is probably related. If you get a "package/version cannot be found" error from the NuGet client, it doesn't necessarily mean that the version isn't there... jsut that the dependency search wasn't successful.

You can just look at the ProGet server to see what packages/versions are there. If it's in the UI, iut will be in the API.

Cheers,
Alana

Hi @rick-kramer_9238 ,

Can you walk us througgh the specifics of what you're seeing / doing?

If you're talking about a connector filter, those only apply to package names and wouldn't have a relation to versions...

Cheers,
Alana

Hi @forbzie22_0253 ,

For the Native API, you would pass in a base-64 encoded string value for byte[] values. Sorry that we don't have any examples; it's not a very friendly API, and we don't call it via JSON ourselves. Most users will configure LDAP or SAML, so so this isn't a big priority for us to document or create an API for as you can understand.

If you find something that works, please do share it here :)

Thanks,
Alana

Hi @daniel-scati,

ProGet generates a signing key when you first create a Debian feed; it's stored in the database, so you won't be able to find it on disk. You can "see" (i.e. download) the key under Manage Feed > "signing key".

We don't really document how the key is generated, but looking at the code... we use BouncyCastle to create a 4096-bit nonexpiring PGP key with <feed-name>@proget as the pgp comment. That's what gets saved in the database, and is what you end up downloading.

So creating a new feed would give you a new signing key.

Hope that helps.

Cheers,
Alana

Hi @scott-wright_8356 ,

This is unfortunately the consequence/downside with frequently-updated packages (like 2-3x daily updates of electron-to-chromium) and metadata caching.

The underlying issue is that different metadata queries have different cache expirations, so the search queries (e.g. "electron-" or "electron-to" or "chromium", etc) will not line up with index queries (e.g. "list electron-to-chromium versions"). There is no solution to this, aside from changing durations or disabling caching.

In general, we very strongly advise against developers "always using the latest version of packages they see", since that's a major attack vector for software supply chains. It also makes build reproducibility basically impossible and gives testing a headache. Instead, we encourage a package approval process where only approved packages are consumable by build servers, as opposed to whatever's the latest version on the net

Best,
Alana

Hi @daniel-scati,

Unfortunately we're not familiar enough with apt to know how to troubleshoot this issue. We do know it works for us (when we follow the instructions) and apparently other users, but not sure why it's not working when you're trying it.

I did a quick search for "GPG error The following signatures were invalid: BADSIG" and found a ton of content, and a really long article that's a bit advertisement-filled, but seems to cover a lot of bases: https://itsfoss.com/solve-gpg-error-signatures-verified-ubuntu/

This is a bit frustrating, but the author mentions:

it's not 'run this command to fix this issue' kind of problem. You have to identify the root cause and then try to follow the suggestions. That leaves quite some work on your end but that's what it is.

If you have any insight on how to resolve this (and specifically something we can add to our troubleshooting docs), please let us know.

Best,
Alana

Hi @v-makkenze_6348 ,

This error can happen if you made certain changes to IIS configuration; in this case, you changed the name of the ProGet site in IIS to something else. That is not supported, so you will get this error.

In general, we recommend moving away from IIS; this is because Microsoft no longer recommends using IIS for modern applications (.NET). And there is weird behavior like this. They only recommend it as a proxy server and legacy application server (Classic ASP, .NET Framework, etc).

Hi @jw , let's move some of these to a new thread, since this is sort of getting a bit long / off topic. I'll reply here then lock the thread, but feel free to reply as a new thread for any one of these topics.

First, if you haven't already, I'd submit your database so we can test using your database. I don't know what has/hasn't been tested yet, but that's what we plan to do this week.

Internal Ids --- we will likely not include internal Ids in the /sca endpoints; those are only exposed in the native API (which we don't recommend using). We really don't you to use the Native API since it arbitrarily changes.

Docs -- the docs are going to be a little behind, but those will come out shortly after; note that our primary API will become a CLI, so the API docs will favor examples for pgutil. This will actually make building out new APIs a lot easier, since we can just point to GitHub code to show how it works, etc.

SCA Events -- these will also trigger when you upload a noncompliant package and one is discovered in an overnight scan (either of packages or builds). This is our starting point from zero, so we'll see what feedback we have and adjust accordingly.

Hi @akillen_5633 ,

Sorry on the slow response, but we're kinda stuck on this one; for some reason, the query to list packages is timing out. That's really unexpected, especially in 2023.31.

If it was related to heavy load, I would expect a lot more symptoms - like API calls, etc timing out. That doesn't seem to be the case.

The only thing that we can think of is that something is wrong with SQL Server, in so much as it needs some maintenance.:

• run exec sp_updatestats
• rebuild indexes (see https://docs.inedo.com/docs/installation-sql-server#advanced-maintenance)

We've also seen some old/unpatched versions of SQL Server cause strange performance problems due to some obscure bugs in SQL Server. So that's another thing to consider.

If that doesn't do the trick, you may need to dig in a bit deeper to figure out what's going on, and see what SQL Server is doing behind-the-scenes. Ultimately this is just executing the Packages_GetPackages stored procedure, which is basically just doing a straight-forward select on FeedPackageVersions_ExtendedWithMaven view.

Best,
Alana

@v-makkenze_6348 thanks for clarifying - that's not how we intended to use the feature, but hopefully the ProGet 2024 model will work better.

In ProGet 2024, they are called Builds, and Builds have a Release Number. They are also auto-archived, and have a kind of Build Stage.

Sorry but I don't yet have screenshots, but there is some documentation:
https://docs.inedo.com/docs/proget-sca-builds

Hi @jw ,

We're in the final stretches of ProGet 2024 now (looks like we're on ci-27 as of this morning); you're welcome to try it, we've been using it for a bit ourselves. It seems to mostly work.

You're also welcome to send us a BAK of your database (opne a ticket for that, and we'll send a secure link to upload). Then we can test upgrades and make sure the UI/UX works with your data.

Our plan as of now is to do some final touches, testing, and bug fixes next week, and then ship 2024.0 on Friday assuming it passes the final tests. And I'm sure we'll be shipping a 2024.1 shortly after :)

We don't plan on doing an RC however; those are mostly for getting "patch" maintenance releases sooner.

Thanks,
Alana

@v-makkenze_6348 Thanks, we'll add this to our "final touches" in PG2024 :)

@v-makkenze_6348 we'd definitely be curious to learn more about the use case. We only expect like 1-2 sboms per build (or "release" as it's called in ProGet 2023) -- the idea is that it's one SBOM for the nuget packages, one for npm, etc. Maybe a big monolith will have more, but not more than a handful.

Hi @v-makkenze_6348 ,

This was all totally rewrite in ProGet 2024 (releasing in a few weeks), so we don't anticipate that we'll see these errors.

If you want to send us a database backup, we'd be happy to use it in our testing, and make sure it works after the ProGet 2024 upgrade. Reduced risk for you, more testing and real-world data for us :)

Anyway, if you want to do that, please submit a ticket so that we can send you a secure link to upload the database BAK file.

Cheers,
Alana

Hello @v-makkenze_6348 ,

We're aware of this issue, and it's related to NuGet packages with four-part versions that end in zero, and the way the package is handled behind the scenes. It's a fairly involved/complex issue that we need to fix in a major version -- and we've already done that, in ProGet 2024 :)

We expect it to release soon. You'll need to delete the cached package then re-add it. We've tested this exact scenario w/ SCA Builds/Releases.

Thanks
Alana

Thanks for the detailed information @proget-markus-koban_7308 !

So I gather that "Group1" and "Group2" could be built-in ProGet groups that you would create ahead of time. So I think this would then simplify permissions and have to set up fewer users.

This is probably something easy enough to experiment with in a maintenance release down the line. However it's really specific so we'd put this in the category of a Enterprise-customer feature request, and something that we would do in collaboration with a customer.

So best to talk with your account manager on getting this process started :)

Cheers,
Alana

Thank you very much for the detailed analysis @frei_zs !

I agree, this seems like it's worth trying. And hopefully it won't break :)

We'll try to get this in the next maintenance release on Friday via PG-2618; if it's something we think is worth a pre-release/test cycle, we'll let you know, but probably simple and harmless enough to do.

Clearly "their" files have new lines, and the specs don't say it's "wrong" so far as I can tell.

Hi @udi-moshe_0021,

Here is the license restrictions per edition:
https://docs.inedo.com/docs/proget-administration-license

Vulnerability Scanning is not available n ProGet Free; you would need a paid license for that. You may see some information in ProGet free, but it's mostly intended to bring awareness to the feature and encourage users to evaluate/purchase the software.

Cheers,
Alana

Hi @udi-moshe_0021 ,

Your configuration is not possible.

1. ProGet Free Edition does not support vulnerability scanning, so this is not possible in any scenario (airgap or online). You will need at least ProGet Basic to have some vulnerability support.
2. ProGet Free Edition does not support connecting to other ProGet instances. You will need at least three ProGet Basic licenses to have three instances (dmz, lan, and airgapped)

Your configuration is possible with ProGet Basic. ProGet paid editions include an offline vulnerability database that will be updated every time you upgrade ProGet.

Note that, after a steady decline in service and data quality, ProGet no longer relies on the free, third-party OSS Index. Instead, ProGet uses industry-leading vulnerability and malicious package detection from our own Inedo Security Labs. OSS Index integration will be fully removed in ProGet 2024.

Hi @udi-moshe_0021 ,

Microsoft no longer recommends using IIS for .NET anymore and similarly we've shifted our guidance to use the built-in web server (i.e. Kestrel) the same. There are no pros to IIS, only cons.

Thanks,
Alana

Hi @frei_zs ,

Thanks for clarifying; I'm not at all familiar with the ecosystem and I really don't know how to use deb/aptly/etc. I also don't know what a Packages-files file is.

However, I can say that ProGet provides provides endpoints for two "files":

• https://wiki.debian.org/DebianRepository/Format#A.22Packages.22_Indices
• https://wiki.debian.org/DebianRepository/Format#A.22Release.22_files

These are dynamically generated by ProGet, and we've not run into any issues nor have other users expressed issues. That doesn't mean they're error-free, it just means we don't know what's wrong since we tried to follow the spec and it worked for us/others.

I don't know what the URL is for these offhand, but if you use a traffic capturing tool, you can see exactly what deb is requesting.

If you can help us identify what's wrong with the output generated by ProGet, there's probably good chance we can fix them. We'd also want to know why it "works on our machine" and others.

Thanks,
Alana

Hi @frei_zs ,

Unfortunately we don't know what aptly is doing behind-the-scenes and can't guess what could be going on here. I don't believe that ProGet is generating that file; it looks like something aptly is doing based on data downloaded from ProGet.

ProGet implements a Debian repository as specified here:
https://wiki.debian.org/DebianRepository

It's possible that there's a bug in our implementation, or a bug in aptly, or both. But we can't really track it down with the information here :(

Your best bet would be to start with the aptly team, and to see if they have any idea.

Cheers,
Alana

Hi @philippe-camelio_3885 ,

We haven't investigated or changed this code in very many years (especially within the last year), so I wouldn't expect a changed result.

Can you try the same troubleshooting steps as above? To find out where the invalid JSON is? Maybe it's comma again?

FYI - we use Newtonsoft.Json for both serializing and deserializing (as you can see from error). It's really odd to be generating invalid JSON, but that's what the message is It could be related to an obscure bug, etc. We just have no idea and haven't investigated in past year.

Thanks,
Alana

@frei_zs I'm also replied to your ticket (EDO-10276), but wanted to reply here as well. I'm going to lock this thread after, since it's a different issue.

Unfortunately "tar" files are more of a convention than a standard, and not all libraries can read files created with different libraries. We are using one of the most "forgiving" tar libraries (we use four different ones!) in this particular scenario, but maybe aptly conventions aren't forgiving enough?

FYI - here is what we're doing with the library

public byte[] ReadControlBytes()
{
    using var control = TarReader.Open(this.Control);
    while (control.MoveToNextEntry())
    {
        if (control.Entry.Key == "./control")
        {
            var bytes = new byte[control.Entry.Size];
            using var entry = control.OpenEntryStream();
            ReadBlock(entry, bytes);
            return bytes;
        }
    }

    throw new InvalidPackageException("Package does not have a control file.");
}

We will need to inspect the file and see if we can determine what's wrong, and if it's an easy fix, we'll do it.

Hi @philippe-camelio_3885 ,

Thanks for sharing that, I was able to find the issue.

The two feeds - public-ubuntu are missing public-zabbix are missing the property feedType. This is a bug in BuildMaster for not validating the data in that case and in ProGet for not sending it. So we will fix both:

• PG-2617 FIX: FeedManagement API not returning feedType for debian feeds
• BM-3942 FIX: Improve error handling for ProGet connection calidation

In the meantime, as a work-around, you can block those feeds from your API key, so they can't be read. They aren't usable in BuildMaster anyway, and that will prevent the bad data from being returned, which is what's making the API break.

Thanks,
Alana

@hashim-abu-gellban_3562 nice find, correct that was a typo :)

Hi @hashim-abu-gellban_3562 ,

If you need to authenticate to the feed, you need to pass an API key using Basic authentication., with api as the username and your key as the password.

Here is one way to do this in PowerShell.

$user = 'api'
$pass = 'abcdefg12345'
$pair = "$($user):$($pass)"
$encodedCreds = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($pair))
$basicAuthValue = "Basic $encodedCreds"
$Headers = @{
    Authorization = $basicAuthValue
}

$url = "https://myprogetserver/feeds/mynuggets/package/mypackage/1.0.0"
$destination = "c:\mypackages\mypackage-1.0.0.zip"
Invoke-WebRequest -Uri $url -OutFile $destination -Headers $Headers

I would recommend first getting your scripts to work without authentication, then add it in later.

Cheers,
Alana

Hi @rick-kramer_9238 ,

We have seen cases where LDAP/AD is painfully slow; one common reason is that "recursive group search" is enabled.

But before digging into that, I would just temporary disable Windows Auth (do this in IIS) and disable LDAP/AD, so that you're only loggin in with a built-in username/password. If it's still really slow, then you know it's unrelated.

Best,
Alana

Hi @v-makkenze_6348,

It's hard to say for sure, but there's clearly some kind of database timeout problem here when running Projects_GetReleaseAnalyzerData . I suppose you could try running that directly, and see if it takes a long time?

I suspect the issue is that you have too many active releases. This is a major issue with ProGet 2023's feature -- it was designed with the assumption that users would archive releases, but we've seen thousands in the field. If you have a lot of active releases, this cause some big performance issues.

ProGet 2024 auto-archives builds (the new word for releases).

Cheers,
Alana

Good news @m-karing_2439 ,

This works in ProGet 2024! More specifically, when rewriting/refactoring the PyPi feed, we added support for this "unconventional" repository - specifically, one that doesn't follow the /simple convention or use any of the JSON/warehouse api.

Cheers,
Alana

Hi @philippe-camelio_3885 ,

Can you share the results of /api/management/feeds/list (on ProGet) using the API token you specified?

With that we can hopefully spot something.

Thanks,
Alana

Hi @jw

You're correct, the general design philosophy is to hide elements (links, buttons, pages, panels, etc.) when a user does not have the appropriate permissions.

As you also might imagine, it's hard to get that right all the time and obviously it's not a high-priority in testing (internally) or reporting (users/externally).... so if you spot places where it's incorrect, let us know. We're always keen to improve the UI/UX :)

Best,
Alana

Hi @hashim-abu-gellban_3562 ,

If you plan to use the NuGet API, it's best to familiarize yourself with how it works. We do not document this API nor provide examples, we simply implement Microsoft's API. Here area few links that may be helpful:

• https://learn.microsoft.com/en-us/nuget/api/overview
• https://learn.microsoft.com/en-us/nuget/api/package-publish-resource

When Basic authentication is required, you can use api/{your-key} for username/password. You can learn more about API keys in ProGet here:

• https://docs.inedo.com/docs/proget-administration-security-api-keys

As an alternative, you may find ProGet's Common Package API to be easier to use; we also document it and have several examples:

• https://docs.inedo.com/docs/proget-api-common-package

Best,
Alana

@forbzie22_0253 you can use the same ProGet Free on multiple instances

Thanks for the bug report @philippe-camelio_3885 !

I logged as OT-508 , and we'll target it an upcoming maintenance release :)

Hi @scott-wright_8356 ,

You can ignore that message; not sure how/why it occurred, but the consequence is that the message that the license key was updated wasn't immediately dispatched to the other nodes due to some timint issue. So that means it could take a few minutes for the other nodes to reflect the new license key.

We should probably just ignore that error. let us know if you keep seeing "No primary service node has been registered." and we can investigate further.

Best,
Alana

Thanks @jw, we still aren't quite sure what's behind this, but we rewrote PgvdVulnerabilities_UpdateIndex procedure to run much faster:

This will be included in ProGet 2023.32 via PG-2615

I just published ProGet 2023.32-rc.1 as a pre-release ; would you mind to try it out on your test server, since you can reproduce it?

https://docs.inedo.com/docs/howto-install-prerelease-product-versions

Hi @v-makkenze_6348 ,

I wasn't sure what version you're on. I'm not able to reproduce this in ProGet 2023.32, so I wonder if it's a possibly a bug in an earlier version of ProGet 2023? We recently made some fixes.

How did you try to add the license as Package name?

Did you manually edit the license, or use the dialog to add the entry?

Thanks,
Alana

Hi @v-makkenze_6348,

Just want to confirm here -- it sounds like it's working, except the issue now that you're only seeing 634 packages but not 363?

One thing I suspect is that one of the packageurls in the SBOM is invalid (incorrect format). Are you able to find which item isn't being imported?

It might be missing a version or something else?

Thanks,
Alana

@jw That is so weird.

Is it always failing with the follow?

Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host..

Looking over your Prod dates... did you happen to upgrade after 2024.03.14? Or maybe that's when you enabled the preview feature?

Could you try running sp_updatestats and cleaning fragmentation on those tables usig SQL Management Studio? Clearly there's something we're missing here...

Thanks,
Alana

Hi @Justinvolved ,

This is not uncommon with PowerShell; in general the processes will be closed, but there are enough scenarios with long-running/hanging PowerShell scripts where those processes will report termination but the process will not be terminated. So they can stick around

I'd recommend using the Inedo Agent instead, even if it's on the same sever. That gives better process isolation compared to the local agent, and you shouldn't see this behavior for too long. The local agent runs in-process.

Cheers,
Alana

Hi @jw ,

This job should take like a minute tops. It's inserting/updating about 50k vulnerability records (PgvdVulnerabilities) and maybe 200k related package records (PgvdPackageNames). The later packages tend to have more related packages, but not that many. In either case that's not a lot for SQL Server.

Any help in troubleshooting would be appreciated, since we're kind of at a loss. Behind the scenes, the PgvdVulnerabilities_UpdateIndex procedure is being called with batches of 1000 vulnerability records, and it's exclusively locking both tables.

We noticed that micro-instances of SQL Server (e.g. 1 core / 512MB ram) would fail without batching, but otherwise it completes in about 5 minutes. I assume you're not running that?

One user reported an unpatched SQL 2016 had a severe performance issue with an OUTPUT clause we were using, so we stopped using that. Now it works in that version.

Maybe it's another SQL Server bug? Or perhaps something we're otherwise missing?

Maybe a forced sp_updatestats would do the trick? Or cleaning up fragmentation on those tables (again, shouldn't be a problem....)

Any insight would be helpful. We don't know how to rewrite this any more effectively, and batches of 1000 seem about as small as we want to make them.

Thanks,
Alana

FYI - we plan to fix this in ProGet 2023.32 via PG-2613