administrators

Hi @it_9582 ,

What version of ProGet are you using? There was a recent regression (PG-3204) that was fixed in ProGet 2025.19 with regards to symbol server. S hopefully upgrading will fix the issue.

Cheers,
Alana

Hi @paul-moors_5682 ,

We'll definitely keep an eye on this after ProGet 2026; we're doing some big improvements for vulnerability management, which will probably push more folks out of the Approval Workflow.

One thing I like about an in-built workflow is that it demos really well and makes it so much easier to see/understand how an approval workflow could work. While I personally love the idea of "approved packages only", it's so hard to recommend that workflow in practice.

Anyway, let us know how your approval-only journey goes. We tried it internally here and it was a flop... just Microsoft's growing dotnet dependencies alone made it impractical.

Cheers,
Alex

Hi @Valentijn,

We had a hiccup in one of our edge nodes that was preventing this version from showing up. If you check now, it should be available.

Thanks,
Rich

Hi @scusson_9923 ,

Looks like this is a bug in not overriding the job/execution status; the force normal statement should make it "green" and a normal execution status. Anyway we'll get it fixed via OT-524.

Cheers,
Steve

Hi @adoran_4131 ,

It looks like the 404 error is occurring while trying to download the Release file (i.e. the index) for the repository. The file is being downloaded from this URL:

{connector-url}/dists/{distro}/Release"

And that URL is returning a 404. So make sure you are entering the correct distro in the connector.

Thanks,
Steve

Hi @paul-moors_5682 ,

Thanks for sharing this idea; it's interesting idea and is actually something we talked about internally over the years.

However, after several conversations with a few customers who used the Package Promotion Workflow, they wouldn't find any value or use the feature. The reason is, they already have workflow tools (ServiceNow, JIRA) that document/automate SOP like these, and some will even do a quick API call once the package is approved.

In other words, everything happens in the workflow tool -- which is used for every other SOP from architecture review to vacation requests.

Now just to comment on the "best practices" part; we are working on revising our practices, but we don't consider "package promotion" the best practice anymore. Instead, we consider it the "option with the most control (and highest cost)".

If that level of control is not needed by the organization, then it shouldn't be used -- given the explosion of dependencies (1000+ for the average npm project), it's a lot of process to maintain. A lot of customers (military contractors, etc) are used to that level of process/control and it's fine.

But if you try to institute this at an organization without this process-heavy culture, you'll get a "rebellion" and just see shadow-IT and bypassing of these rules. And they won't get fired or even scolded.

And that brings us back to why no one seems to want this type of system -- companies with this level of process use ServiceNow/JIRA for everything already.

Cheers,
Alex

Hi @matthias-schmitz_2037 ,

The "Signature ... was created after the --not-after date" message is coming from sqv (Sequoia-PGP verifier), which newer versions of APT use for signature verification.

It almost always indicates a system clock problem on the affected machine, not a repository problem, and often means "The system clock is behind the signature creation time."

So bottom line, I would check the clocks to make sure they are accurate.

Thanks,
Steve

Hi @scusson_9923 ,

The message is expected, but you should see scriptExists: false written at the end, and aNormal status (i.e. green) for the execution.

Is that not the case?

Thanks,
Steve

Hi @scusson_9923 ,

Sorry on the slow reply; i wanted to test this, but didn't get a chance and figure I'd just share this now (which should work):

set $scriptExists = true;

try
{
    Get-Asset FooBar.ps1
    (
        Overwrite: true,
        Type: Script,
        To: D:\temp\FooBar.ps1
    );
}
catch
{
    set $scriptExists = false;
    force normal;
}

Log-Information scriptExists: $scriptExists;

Cheers,
Steve

Hi @v-makkenze_6348 ,

This is a regression introduced from ProGet 2025.20's changes to malicious package handling. It's not intentional, and only the specific versions should be blocked (8.10.1, 9.1.1, 10.1.6, 10.1.7)

We'll get it fixed via PG-3227 in the next maintenance release (scheduled for this Friday, but we may do a pre-release sooner). For now your best bet is to rollback to ProGet 2025.19.

Thanks,
Steve