Posts made by atripp

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

Hi @m-karing_2439 ,

Unfortunately, this repository doesn't following PyPI repository conventions.

For example:

• No way to see latest packages (should be https://download.pytorch.org/whl/cu118/rss/updates.xml)
• Does not return anything for /simple listing (e.g. https://download.pytorch.org/whl/cu118/simple)
• Does not support JSON-based API to retrieve package metatadata

I guess it "happens to work" in pip , or perhaps they install a plugin that allows it to work... but ProGet is designed around PyPi repository specs. which is why a non-confirming download site won't work very well.
I'll add a note to investigate this further, but for the time being you should just download the wheels and upload them to a feed in ProGet.

Cheers,
Alana

Hi @scott-wright_8356,

I looked into this further; for Maven feeds, the Connector Health Check simply queries the downloaded index. If there is no downloaded index, then it reports back as healthy. If there's an error with the index, it reports an error. However, most maven repositories don't have a downloadable index.

Anyway the health check is not very useful, and we plan to revisit the functionality in the future, since there's really no way to determine if ProGet can download an artifact unless you know the exact name.

Thanks,
Alana

@appplat_4310 thanks for the update!

We also applied the patch to the next maintenance release, so you shouldn't have any issues going forward then!

Hi @scott-wright_8356,

It's a bit hard to figure out how to help or troubleshoot with the information here, but a few key points:

• A "healthy" Maven connector doesn't really mean much; just that the URL can be accessed by the ProGet server.
• A Maven repository (like the one you are linking to) is just a "web file system" with url/folder based conventions
• A Maven "package" consists of a .pom file and zero or more other files (.jar); think of it liked an unzipped package that you can add/delete files from
• This is why you can't import only .jar files - you need the .pom file (which serves as the package manifest)
• Sometime marvin "packages" contain malformed .pom files that happen to work in some versions of the client, and ProGet will sometimes error on reading those; maybe that's what happening here

To help on this, we'll need to know specifically where the issue is and have instructions on how to reproduce it on a new feed/instance of ProGet.

First, I would start by trying to download the .pom file and .jar files from Google (like that gradle one you found), then upload them to ProGet from the Web UI. If that doesn't work, then we know the POM file is probably bad, and we can investigate it.

Next, I would try to pull the pom/jar from a connector. If that doesn't work (but uploading it does), then maybe the "API" for that repository is incorrect. And we can investigate it.

Best,
Alana

Hi @scott-wright_8356 ,

I'm not sure, but based on this URL:
https://maven.google.com/web/index.html#android.arch.core:common:1.1.1

I can see that the POM for android.arch.core.common 1.1.1 is located here:
https://dl.google.com/android/maven2/android/arch/core/common/1.1.1/common-1.1.1.pom

So the base URL would be:
https://dl.google.com/android/maven2

That should work, since maven works by convention. You will not see a listing of artifacts unfortunately, since Maven does not provide an index. You just need to know the articats by name, then append maven-metadata.xml.

As expected, the metadata file for that artifact is here:
https://dl.google.com/android/maven2/android/arch/core/common/maven-metadata.xml

Cheers,
Alana

Hi @forbzie22_0253 , that's only possible in the one-off GUI option. It's not possible if you're using a drop path

Hello, just letting you know we're aware of the issue and plan to investigate/fix soon! And we hope then to get your feedback on the preview feature :)

Hi @scott-wright_8356 ,

Thanks; it sounds like the underlying issue is indeed Google Android connector you added. I don't have an information or idea on why that might be the case... some third-party repos (Maven, PyPi, NuGet, etc.) are just really slow and buggy.

ProGet is basically acting like a proxy server here, so "garbage in, garbage out" applies - if the connector is slow and error-prone, then you will experience slowness and errors.

Sometimes third-party repos will create packages that don't follow the specifications but just happen to work in certain versions of clients. That could be what's happening here. In cases like that, we can really only address those on a case-by-case basis, and we'd need to know exactly how to reproduce the error and investigate it later.

Best,
Alana