Posts made by atripp

@philippe-camelio_3885 thanks! We were looking at BuildMaster. It looks like the issue is in Otter after all. We'll get it fixed via OT-509 soon!

Hi @forbzie22_0253 ,

This is not supported for ProGet Free edition at this time; but as long as ProGet is connected to the internet, it will auto-activate.

Thanks,
Alana

Hi @Darren-Gipson_6156 ,

That's great you were able to find the code to change, at least to help find more information. Since you've got that far, I would recommend just bundling it as a zip file and adding the extension to ProGet to try it out:
https://docs.inedo.com/docs/proget-administration-extensions

Let us know if you run into any issues with that; that will probably amke it easiest to iterate, so you don't have to wait for us to build pre-release extensions .

Thanks,
Alana

Hi @pawel-ostrowski_5669 ,

Unfortunately this is going to be tricky to troubleshoot, but in general a timeout will occur because SQL Server is taking too long to respond to a query. This typically related to query performance, but it can also be caused by network issues.

Looking at the stack traces you shared, these are very basic, highly performative queries that would instantly return a single row. There is nothing that should be slowing down those queries, which means could probably rule out query performance.

The fact that the timeouts occur randomly, during heavy and lighter load is also an indicator that it's probably not performance related, and a sign of network issues.

And finally, the fact that you profiled and didn't see any problems is a good sign this is not performance related. That's my current thinking at least.

Otherwise, I'm not familiar with "Attention" events. That must be something done internally by the driver? The SQL Server docs says this:

The Attention event class indicates that an attention event, such as cancel, client-interrupt requests, or broken client connections, has occurred. Cancel operations can also be seen as part of implementing data access driver time-outs.

I'm not sure what that means to be honest, but I found this article that might be of use:
https://www.red-gate.com/simple-talk/blogs/identifying-client-timeouts/

I think this would be worth getting Microsoft's SQL Server team involved, because we really don't know where to go form here, and they would have more experience troubleshooting this (especially if it's network-related) than we do.

Thanks,
Alana

Hi @jw ,

You are technically correct. In retrospect, it's not a perfect design.

However, this behavior is based on most user perception/desire. "Noncompliant / Inconclusive / Error" are all considered "Red" conditions (i.e. bad/blocked, etc.), and to the user they are basically the same thing. "Warn" is a "Yellow" condition (i.e. caution).

A package that would only become "Yellow" if a rule is violated shouldn't turn "Red" if that rule can't be evaluated. So that's why it's Warn.

This addresses one of the major complaints about the "missing packages" problem in ProGet 2023, and the "Red" packages in the ProGet 2024 preview feature.

Thanks,
Alana

Hi @Darren-Gipson_6156 ,

The Netbios mapping is used to convert a username from DOMAIN\username to username@domain.com . You can see how it works in the code here:
https://github.com/Inedo/inedox-inedocore/blob/master/InedoCore/InedoExtension/UserDirectories/ADUserDirectoryV4.cs#L228

I'm not sure if that helps. But before getting integrated authentication working, I would make sure you can login username@company.com and your domain password. Once you can do that, then adding WIA will basically just bypass the password check, but you may need to convert that DOMAIN to company.com

Alana

Hi @Darren-Gipson_6156 ,

This error means that the username being passed from Windows (e.g. MYDOMAIN\jdoe) cannot be found on the domain.

This can mean that the netbios alias domain mapping is incorrect (e.g. MYDOMAIN) or that there are some other issues locating the user in the configured directory. Your best bet is to "play around" with searching and settings under the Advanced settings tab of the Directory (under Admin > Security > edit)

Note you can also try searching for users on that page as well, using the multi-button link in the top-right corner of the page.

In addition, you can see the information about the user by navigating to /debug/integrated-auth, and that might give some kind of clue where to start.

Hope that helps point you in the right direction,

Alana

@jw thanks for the detailed research, this definitely is wrong. We should log the package (I think that was there at one point), but also this should be inconclusive.

We'll get this fixed via PG-2676 in an upcoming maintenance release, hopefully this Friday's or the following :)

Hi @daniel-scati ,

Thanks for sharing this; Debian packages are a "little weird" in they require that qualifier, and it'd be nice if it was a little more intuitive. I wonder if there's an additional qualifier required?

We'd really like to improve the experience. What does this Package look like in the ProGet UI? Can you use the Common Package API to find what information is returned in the purl of the package, when you list it?

Thanks,
Alana

Hi @rick-kramer_9238 ,

You should avoid the OData V2 API; it's been deprecated for many years, it's very slow/bulky, and it will likely have bugs in NuGet client, etc.

If you're getting those warnings, some user/script is making queries that are unsupported by nuget.org.

Cheers,
Alana

Hi @am-infrastruktur_3111 ,

Chocolatey packages are scanned for viruses, so you will see those pop up. For example, pathdebug 0.3.4 should show up in ProGet's vulnerability system:
https://security.inedo.com/vulnerability/details/PGV-2420934

Otherwise, there is unfortunately no standardized/consistent naming for Windows software (unlike APK, APT, RPM, etc), so there's no way to associate a vulnerability report like CVE-2024-21392 with a software package.

In this case, Microsoft calls the effected software ".NET 8.0", not .NET or dotnet, etc. In Other reports, they call it ".NET8", etc.

And you can see that it translates a little weird n the CVE report as well:
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21392

".NET 8.0 affected from 1.0.0 before 8.0.3 " - weird, right?

This is a known issue in the industry for many years, and it would need to be address by Microsoft first. It's sadly not on their priority list.

Best,
Alana

Hi @rick-kramer_9238,

In all cases, you'll need to configure ProGet to listen to a certain URL; this basically involves editing the ProGet configuration file, which the web page will do for you (or you can edit yourself).

If you're going to do port sharing (i.e. have multiple applications on the server listen/respond
on port 443 for example), the you also need register the URL and certificate with Windows using the netssh commands.

If you're not doing port sharing (i.e. ProGet is only application listening on 443) then no need to use netsh.

Hope that helps,
Alana

Hi @jw ,

Thanks for the update, that sounds like a decent work-around for the time being. It will likely be a while before we can develop something more generalized.

I'm curious if you looked at any of the audit endpoints/commands in pgutil yet? That's kind of the direction we're thinking it will make sense to go - basically pgutil packages audit --package=myGroup/myPackage --version=1.2.3

I don't know what the HTTP Endpoint is offhand, but that does make sense to add something to PackageInfo, since we have it in the database already pretty easily. We could display a complianceStatus (Compliant, Warn, Noncompliant, Inconclusive, Error) and a complianceDetail string - that's what we have in the database. I think properties are easier to work with than objects... what do you think?

As for Download Package behavior -- we do intend to get the Common Packages API to work with connectors. That involves a lot of refactoring that just didn't make it in ProGet 2024 (only PyPi and Apk were refactored).

Cheers,
Alana

Thanks so much @jw! We'll get these fixed in an upcoming maintenance release via PG-2651

Looks like we forgot to add these after applying permissions on top., and the way our security review works, it prioritizes making sure the pages are secure (versus links), so it's easy to miss.

Anyway we'll try to add that to our new feature checklist... easy to forget to do since we check permissions on the page itself, not on where we link to the page.

@daniel-scati great work finding that :)

The Feed Description is written in the Release Index, and the Debian "Stanza" format is kind of weird like that.

However, newlines should already be replaced...

var desc = FeedCache.GetFeed(this.feedId)?.Feed_Description;
if (!string.IsNullOrWhiteSpace(desc))
    writer.WriteLine($"Description: {desc.ReplaceLineEndings("\n ")}");

A blank line with a space isn't supposed to create a new "stanza", but maybe it is in your version?? We'll look closer; perhaps we should just strip the newline altogether and replace it with a space.

Cheers,
Alana

Thanks for clarifying, that's good to know taht solved the problem! I looked again and found it. Maybe I was looking in the wrong database

It doesn't look like bootstrap.less is in your feeds, but it is in the PackageNameIds table:

Just because it's in that table doesn't mean you're using it; we use the PackageName_Id as a surrogate ID instead of the package name. There should only be one entry, since NuGet package names are case insensitive.

anyway, I think I found the culprit -- looks like it was added during a vulnerability database update. MAybe there is some bug that didn't properly check the casing

Anyways, that's what we have to clean-up up :)

Hi @v-makkenze_6348 ,

Just to give you an update, we're still working on this; there's a lot of duplicated data and figuring out how to clean it up is a challenge. It's hard to say where it came from.

For example, your database has internal ids for both bootstrap.less-3.4.1 and Bootstrap.Less-3.4.1, and we need to figure out how safely merge those. At this point, we're thinking we're just going to do one massive SQL Script to do a cleanup. Then, we can try to figure out where the duplicates are coming from.

Regarding VicreaNeuronGegevensmagazijnContracts package, we can't find that in your database. But I assume that's a new package/version. If you have a newer backup, please upload that to the link we sent - we can check it in there. I think its' related to 4-part version, but just want to check.

Cheers,
Alana

Hi @scott-goodwin_8239 ,

Thanks for the detailed report; you're right, it's definitely related to some kind of library/platform problem. There seems to be a known bug in one of the libraries that can cause this in some cases on Linux.

Fortunately we already identified a good workaround/fix to this issue (PG-2626), and we plan to ship it on Friday evening; please let us know if you'd like to try this in a prerelease version.

Thanks,
Alana

Hi @scott-wright_8356 ,

Thanks; it's hard to say what the issue is, and unfortunately we don't really have any good troubleshooting tools here. That error is coming from within SQL Lite, and we can't reproduce it when we do a SMB share.

I wonder if you can follow some of the same troubleshooting steps? Specifcally like using ProcMon or mounting the network drive with SysInternals?

We just don't really have any means to troubleshoot this, so we'd need to go back to the drawing board to figure out why it doesn't work for you. You're welcome to keep exploring C#, but let me share the code that's closer to ProGet.

Here is the code that ProGet is running. It's kind of similar, but a little different. Note we are using System.Data.SQLite.Core-1.0.118 and .NET6.

private static SQLiteConnection OpenOrCreateDatabase(string fileName, out Dictionary<string, string> config)
{
    var str = new SQLiteConnectionStringBuilder
    {
        DataSource = fileName,
        FailIfMissing = false
    }.ToString();

    if (FileEx.Exists(fileName))
    {
        var conn = new SQLiteConnection(str);
        try
        {
            conn.Open();

            config = ReadConfig(conn);
            if (config.TryGetValue("SchemaVersion", out var versionStr))
            {
                int version = int.Parse(versionStr);
                if (version == 1)
                {
                    using var cmd2 = new SQLiteCommand(GetScript("UpdateSchemaToV2"), conn);
                    cmd2.ExecuteNonQuery();
                    return conn;
                }
                else if (version == 2)
                {
                    return conn;
                }
            }
        }
        catch
        {
        }

        conn?.Dispose();
        FileEx.Delete(fileName);
    }
    else
    {
        DirectoryEx.Create(PathEx.GetDirectoryName(fileName));
    }

    var conn2 = new SQLiteConnection(str);
    conn2.Open();

    using var cmd = new SQLiteCommand(GetScript("CreateSchema"), conn2);
    cmd.ExecuteNonQuery();

    cmd.CommandText = GetScript("UpdateSchemaToV2");
    cmd.ExecuteNonQuery();

    config = ReadConfig(conn2);

    return conn2;
}
private static Dictionary<string, string> ReadConfig(SQLiteConnection conn)
{
    using var cmd = new SQLiteCommand("SELECT Key_Name, Value_Text FROM OtherData", conn);
    using var reader = cmd.ExecuteReader();

    var res = new Dictionary<string, string>();

    while (reader.Read())
    {
        var key = reader.GetString(0);
        var value = reader.IsDBNull(1) ? null : reader.GetString(1);
        res[key] = value;
    }

    return res;
}

Here is the CreateSchema script:

CREATE TABLE OtherData
(
    Key_Name TEXT PRIMARY KEY NOT NULL,
    Value_Text TEXT
);

INSERT INTO OtherData (Key_Name, Value_Text) VALUES ('SchemaVersion', '1');

CREATE TABLE FetchInfo
(
    Subdir_Name TEXT PRIMARY KEY NOT NULL,
    Modified_Date INTEGER,
    Fetch_Date INTEGER NOT NULL
);

CREATE TABLE ChannelData
(
    Package_Name TEXT PRIMARY KEY NOT NULL,
    Flags_Value INTEGER NOT NULL,
    Description_Text TEXT,
    DevUrl_Text TEXT,
    DocSourceUrl_Text TEXT,
    DocUrl_Text TEXT,
    Home_Text TEXT,
    Icon_Hash TEXT,
    Icon_Url TEXT,
    License_Text TEXT,
    RunExports_Json BLOB,
    SourceGitUrl_Text TEXT,
    SourceUrl_Text TEXT,
    Summary_Text TEXT,
    Timestamp_Value INTEGER,
    Version_Text TEXT NOT NULL,
    Subdirs_Csv TEXT NOT NULL
);

CREATE TABLE RepoData
(
    Package_Name TEXT NOT NULL,
    Subdir_Name TEXT NOT NULL,
    Version_Text TEXT NOT NULL,
    Build_Text TEXT NOT NULL,
    ArchiveType_Code INTEGER NOT NULL,
    Build_Number INTEGER NOT NULL,
    License_Text TEXT,
    LicenseFamily_Text TEXT,
    MD5_Hash BLOB,
    SHA256_Hash BLOB,
    Package_Size INTEGER NOT NULL,
    Timestamp_Value INTEGER,
    Dependencies_Json BLOB,
    AppEntry_Text TEXT,
    AppType_Text TEXT,
    Type_Text TEXT,
    Summary_Text TEXT,
    Icon_Hash BLOB,

    PRIMARY KEY (Package_Name, Version_Text, Subdir_Name, Build_Text, ArchiveType_Code)
);

Here is the UpdateSchemaToV2 script:

UPDATE OtherData
   SET Value_Text = '2'
 WHERE Key_Name = 'SchemaVersion';

ALTER TABLE RepoData
  ADD Constraints_Json BLOB;

From there, it's just a bunch of inserts into those tables. The "unable to open database file" error would probably be occurring in the middle of those, but it's hard to say.

The race condition occurs when multiple threads run OpenOrCreateDatabase at same time. It's rare as I mentioned.

Alana

Hi @philippe-camelio_3885 ,

This is by design, as a common use case is to delete/create a credential with the same name. The design pattern is based around things like Windows Services, and the fact that renaming a username will not update all Windows services, etc.

However, it's really inconvenient, and it'd be nice if there was a " would you like to also rename things in scripts/resources/servers/etc". But there's not, and it's something on our "to consider" list for an upcoming version.

It's easy enough to work-around though - and as an FYI, in BuildMaster, you can just export the infrastructure, then reimport it after search/replacing the credential name in the JSON file.

Cheers,
Alana

Hi @v-makkenze_6348 ,

Thanks for the report; please ignore this, it should not be logged in the Diagnostic Center. It's addressed via PG-2625 in ProGet 2024.1

Cheers,
Alana

Hi @scott-wright_8356 ,

ProGet doesn't "directly" work with SMB shares, but instead uses the File System API. As such there's no special configuration or ports required - that's all handled at the operating system level. And it sounds like it's working fine, since other feeds are working.

As for SQL Lite, a few feed types (including conda, debian, rpm, etc.) will use a SQL Lite to "cache" connector information. But a SQL Lite database is just a file stored on disk, as you've noticed - if ProGet can read/write files on an SMB share, there is no reason it wouldn't work.

We haven't had issues in HA configurations with SQL Lite connectors, but we have seen this issue come twice before. One time was a ticket, and it was some "malware" that was blocking the SQL Lite file for security reasons. A more recent thread is here: https://forums.inedo.com/topic/4128

I wonder if you can follow some of the same troubleshooting steps? In the end, this seemed to work:

I was finally able to try this with a mounted network drive (using SysInternals), and that works

We don't really have an alternate solution at this time, but if this continues to be an issue we can definitely consider a node-by-node / local file system configuration.

Thanks,
Alana

Thanks for confirming that @carl-westman_8110 ! That should definitely not be showing up :)

This is definitely a bug on Microsoft's end (we've seen similar in some early distributions of SQL Server 2008). We will work around this in 2024.1 via PG-2624 - we are planning to ship on Friday.

As an FYI, here is the new script:

DECLARE @SQL NVARCHAR(MAX) SET @SQL = ''
SELECT  @SQL = @SQL + 'DROP PROCEDURE ' + QUOTENAME(name) + ' ' FROM sys.procedures WHERE schema_id <> 4
SELECT @SQL = @SQL + 'DROP TYPE ' + QUOTENAME(name) + ' ' FROM sys.table_types  WHERE schema_id <> 4
SELECT  @SQL = @SQL + 'DROP VIEW ' + QUOTENAME(name) + ' ' FROM sys.views  WHERE schema_id <> 4
SELECT  @SQL = @SQL + 'DROP FUNCTION ' + QUOTENAME(name) + ' ' FROM sys.objects WHERE type IN ('FN','TF') and  schema_id <> 4
EXEC sp_executesql @SQL

In the likely event that Azure SQL slips another sys object into those tables, this will at least ignore that error.

@philippe-camelio_3885 thank you much, we just updated the docs :)

Thanks @carl-westman_8110, that's really helpful to see.

I don't know why it didn't show on ours, but I understand that SQL Server creates new databases by copying the model database, so I'm guessing that your instance of SQL Azure must have something off about its model?

Anyway we can modify this script a bit.... can I ask you to check another thing?

I assume it shows up in this query:
select * from sys.objects where name='database_firewall_rules'

Can you what the schema_id and is_ms_shipped values?

Hi @carl-westman_8110,

In ProGet 2024, we took a new approach to upgrading the database; specifically, we cleanup all code in the database that we did not create. We do this by running the following script:

DECLARE @SQL NVARCHAR(MAX) SET @SQL = ''
SELECT  @SQL = @SQL + 'DROP PROCEDURE ' + QUOTENAME(name) + ' ' FROM sys.procedures
SELECT @SQL = @SQL + 'DROP TYPE ' + QUOTENAME(name) + ' ' FROM sys.table_types 
SELECT  @SQL = @SQL + 'DROP VIEW ' + QUOTENAME(name) + ' ' FROM sys.views 
SELECT  @SQL = @SQL + 'DROP FUNCTION ' + QUOTENAME(name) + ' ' FROM sys.objects WHERE type IN ('FN','TF')
EXEC sp_executesql @SQL

Apparently, those queries are returning a system view called database_firewall_rules, which it should be not.

Can you help us troubleshoot/identify what data is being returned in those views? It's supposed to be only user-added code (not system views like database_firewall_rules).

In theory, an empty database (before ProGet is installed) should have nothing returned from any of those tables. Any help you can provide would be great.

Thanks,
Alana

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.