Hello; you should see a checkbox, like this.

However, due to a bug (now fixed via PG-1885) the checkbox wasn't being displayed due to a license validation problem.

It will be fixed in the next maintence release, scheduled for later today

Hello;

That search syntax is really only supported by NuGet v3 API, I think; so, ProGet simply forwards on the query to that API, and returns the results.

But regardless, connector filters need to be applied after the remote feed returns results, because connector filter logic can be more complex that what is supported by the various feed APIs (you can allow Microsoft.* and Inedo.* for example).

More advanced connector filter options are definitely something we've considered, and we'd love to do things like "version: 3.*" for example. But, it's a lot more complicated under the hood, and probably isn't even feasible given the nature of feeds.

Alana

@Stephen-Schaff thanks for the bug report, I verified that this may happen depending on permission of user, and which feeds they can/can't use --- but it seems an easy enough fix that we can do via PG-1894 (targeted to next release) - the packages can't be viewed upon clicking, but it's a sub-optimal experience for showing packages they can't see

@scroak_6473 we could definitely try a screen share, but in a case like this (where we have no idea what's wrong), it's mostly digging in the code and trying to think of things to try to get a clue for more information. Currently, I'm at a loss... because the error you have shouldn't be happening, but it clearly is.

So now, I had a new idea. I would like to eliminate Docker from equation, as it handles the
"api" username slightly differently than everywhere else. Plus you can do this all in your browser.

Can you try to visit a restricted (i.e. not anonymous view) NuGet endpoint using the "api" user name, and a password?

For example, it should look like /nuget/NuGetLibraries/v3/index.json, and then your browser should prompt for a Username/Password.

Depending on the result of this, we will explore different code paths, and then might need to add some more debugging codes.

Best,
Alana

Hi @mcascone, I'm afraid it's not possible.

nuget or dotnet nuget tools only understand the NuGet Package Format, and the NuGet API, so there's no way for the tools to use different formats or different APIs...

Hello,

That API will only delete package metadata from the database, not from disk. It's mostly intended for internal use only, and probably shouldn't be exposed to the API. In any case, we don't store the @ with internally, so if you change @myscope to myscope it should work.

Note that the NPM doesn't provide a way to delete packages, and we never implemented it. There hasn't been any demand for it to date, as people don't really delete packages programmatically - but you're definitely welcome to submit a feature request and help us understand why it'd be a value (like, the workflow you use that requires deleting packages, etc).

Alana

Hi @sejhemming_5842

Is there an accepted Code of Practice for managing prerelease stuff?

Yes, the general rules to follow are these:

• Packages are immutable; do not delete/republish packages as part of your normal workflow
• Use Prerelease Packages & Repackaging to take tested/validated prerelease packages to stable packages
• Use Package Promotion to move packages across feeds
• Use Retention Rules to automatically cleanup unused prerelease packages

Do people publish prerelease stuff to a different feed and only post the released stuff to the more public feed? Or is it just expected that once the release is out that the prerelease builds are simply removed from the feed?

Yes to both

On our ProGet Instance, we use both patterns.

• Extensions (plugins) have two feeds: Extensions (Stable) and PrereleaseExtensions; the reason is that we use CI (build automation), and publish a new package on every commit, and these could be really unstable - we don't want anyone using a prerelease extension unless we explicitly point them to it
• Our NuGet libraries have one feed (NuGetLibraries) that has both prerelease and release packages; these are not intended for anyone other than Inedo Engineers, and we have policies, practices, and training in place to make prerelease packages are shipped appropriately

My advice for deciding which pattern to follow would be looking at the consumers of your feeds/packages (i.e. who uses your packages vs who publishes your packages).

Using a single feed that has release and prerelease packages requires more training for developers. If one of your developers accidently uses a prerelease package and commits that, then it's going to cause problems. Even if you catch it before production, it will waste time and resources.

Hi @Stephen-Schaff ,

I'm not sure about the API, but ProGet implements the Chart Repository API, and from a look at that, you should be able to just access index.yaml at the API Endpoint URL

Here is some information about the format of that file: https://helm.sh/docs/topics/chart_repository/#the-index-file

Can you give that a try and let us know what you find out? Cheers :)

Cheers,
Alana

@kichikawa_2913 glad it's working now, you seem to have found the issue.

FYI, you can also configure that value from Advanced Settings page under Admin.

Hello,

The NuGet Client only uses the the -ApiKey you on certain requests to the -Source, specifically the PUT of the package file. Before doing that, it will query the package source using a GET, and in this case, the API Key isn't sent.

The easiest solution is to allow anonymous view access to your feed. That simplifies configuration for all users of your feed.

Alternatively, you will need to add credentials to the PackageSourceCredentials in the NuGet.config file . Note this file exists in several places, please see Config file locations and uses

Cheers,
Alana

Hi @m-lee_3921 ,

Thanks for the heads-up; we'll get this fixed via PG-3059 in the next maintenance release (scheduled for later today).

And you're right -- its basically the same issue. SQL Server silently truncates string values whereas PostgreSQL does not, hence these errors.

We decided to not auto-truncate, since it's better to know about these cases than not. In this case, it's a IPv6 address that was longer than the 20-character limit. We plan to refactor API key logging at some point, so we'll just continue to truncate v6 IPs.

Thanks,
Alana

@shaun-d-scott_2657 Inedo products do not use log4j, so it's not an issue for ProGet :)

See more information here: https://blog.inedo.com/log4shell-high-severity-vulnerabilities

Hi @cronventis ,

Great find - that seems to explain what we're seeing: containerd reports on containers differently than dockerd. So, we'll just search for container images based on configurationblob_digest OR image_digest

This change was trivial, and will be in the next maintenance release (or available as a prerelease upon request) as PG-2081 - scheduled release date is Feb 11.

Cheers,
Alana

Well, that's an interesting way to specify an embedded license file. I don't know if that's a convention or specification, but that seems to be a new way of handling it. It's kind of documented now, which is good: https://docs.npmjs.com/cli/v8/configuring-npm/package-json#license

Anyways, we already handle this for NuGet packages using a URL convention like this:

• No license - packageid://Aspose.Words/21.9.0
• File license -package://Aspose.Words/21.9.0/License\Aspose_End-User-License-Agreement.txt

Those will be defaulted in the fields if the package specifies no license or a file license.

Not sure if it works now for npm packages, but it'd be relatively easy to adoption that convention, and then suggest it when the "license" field starts with "SEE LICENSE IN"...

Anyways we'll investigate this and update in a day or two.

Cheers,
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 @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 @geraldizo_0690 ,

I think the best way for us to proceed with this investigation is to get a copy of your database backup. And as a bonus, we'll validate your database to make sure the upgrade to ProGet 2026 and the new vulnerability management features work nicely :)

I created a secure public link for you, which you can access in this ticket that I've created for you: https://my.inedo.com/tickets/view?ticketNumber=EDO-12790

Just let us know once you've uploaded the BAK file, and we'll take a look and figure it out from there.

Thanks,
Alana

Hi @jonathan-werder_8656,

Oooh that's definitely outdated, thanks for pointing that out! Perhaps we should just delete that article.... but I'll see if we can salvage it.

If you're setting up a new instance of ProGet, that article is not for you -- that's helping you migrate an existing instance. For a new instance, I would just do a standard Windows or Linux installation (use the Embedded database in either case) - there's nothing special about Azure.

For migrating... at this point (i.e. ProGet 2025+), I would just set-up ProGet on the new server using PostgreSQL (the default configuration). Then, export your database from the old server and import it into the new server.

You'll have to deal with the Package Files as well, which is discussed in this (slightly outdated) Migrate an Existing ProGet Installation to a New Server article.

Anyway we'll add these to the list, but let me know if you have any questions in the meantime.

Cheers,
Alana

Hi @rie_6529 ,

There is not -- this is not an action that should be performed regularly at all. It's more a troubleshooting thing that should only be done after some data problem.

If you find yourself having to run this often, it's indicating there's some other issue. In years past, no one really noticed this (and it didn't have any side-effects), but since we added Integrity Checks, the bad data is a lot more visible.

So it'd be best to troubleshoot that and see if we can correct it.

Thanks,
Alana

@joshuagilman_1054 I don't really know PowerShell myself (today I learned you can do classes )... but behind-the-scenes it's .NET, and that means we can use nullable value types.

I tried [int?] (nullable shortcut syntax) and [Nullable<int>] (generics shortcut syntax) but PowerShell isn't so happy with either. So the long way it is...

[System.Nullable``1[[System.Int32]]] $myInt = 0
echo "myInt is $myInt "
$myInt = $null
echo "myInt is $myInt "
$myInt = 1000
echo "myInt is $myInt "

That should do the trick for you, and is close to our JSON Model anyways.