inedo-engineer

Hi @parthu-reddy ,

If you can provide my with some step-by-step instructions (reproduction case), then I can see if if there's a bug in ProGet. However we can't really change the "license file is embedded in the package file" technical requirement.

That said... using custom licenses for blocking package is definitely inappropriate. Please do not do that. It will cause you headaches and probably business disruptions later. There are already tools to prevent users from downloading packages from ProGet, this is not how you want to do it.

The easiest solution here is to align the security team's understanding/expectations align with reality. You don't want to try to configure ProGet in unrealistic ways that will lead to actual problems/risks.

I suspect the security team is conflating "vulnerable packages" with "malware and viruses", so it'd be best to take this opportunity to educate them on how packages / ProGet works.

1. ProGet can prevent users from downloading certain packages, but vulnerable packages are freely available on the internet for download.
2. A vulnerable package is NOT some a "virus in a lab that can escape" and infect a system
3. A package is just a library and cannot run on its own
4. If a user has a copy of vulnerable package, they can't use it to "hack" a system with it nor will it cause any harm
5. Vulnerable packages simply shouldn't be used as building blocks in your own applications

Thanks,
Alana

Thanks @daniel-pardo_5658 , I was able to reproduce it.

It seems to work when you have additional metadata fields. Anyway we'll get it fixed via PG-2935 in the next maintenance release. AS a work-around, you can just download the package, edit the upack.json, and reupload it.

Cheers,
Alana

Hi @parthu-reddy ,

This hasn't changed; to "Set Package Status", you need to first Pull the Package to the feed. From there, you can a compliance rule override of Always Block or Always Allow Downloads.

Thanks,
Alana

Hi @scusson_9923 ,

Thanks for clarifying. You're right, the result is not available as a variable. Instead, the Operation will fail, which means you'd want to handle this via a try/catch.

try
{
    InedoCore::Exec
    (
        FileName: pwsh,
        WorkingDirectory: C:\,
        Arguments: test.ps1,
        ErrorOutputLogLevel: Error,
        OutputLogLevel: Information,
        SuccessExitCode: == 0
    );

    ... operations for success...
}
catch
{
    ... operations upon failure ...
}

Hope that helps,
Alana

Hi @parthu-reddy,

I'm not sure about the specifics of how you've configured this, but in general, the "first download not blocked behavior" is to be expected with certain types of license checking.

Depending on how the author configured the license, ProGet cannot detect a license without the package file... so until the package has been added to the feed in ProGet, (via caching) happens it's considered "Undetected". In your Policy, you have that as "Warn", so it won't be blocked.

It's not technically feasible to handle this any other way, as ProGet streams the file it's downloading from a remote source to the user while also adding it to the feed for caching.

Thanks,
Alana

Hi @v-makkenze_6348,

I apologize for the delay on our side. After testing these two packages (Microsoft.Web.Infrastructure.1.0.0 and System.Net.Http.Formatting.Extension.5.2.3), I'm unable to recreate your error. They download fine for my tests. Can you please try to delete these two cached packages and try it again?

Thanks,
Dan

Hi @scusson_9923 ,

Can you clarify what update you're looking for?

Are you looking for help on how to capture a failure and test on it?

Thanks,
Alana

Hi @caterina,

I'm sorry about this. There looks like there was a conflict with another notifier change. I have created a new ticket, PG-2933, to fix this and it will be released in the next maintenance release.

Thanks,
Dan

Hi @arose_5538,

We just released ProGet 24.0.31 that has the fix included for this so you do not need to specify those extra environment variables.

Thanks,
Rich

Hi @arose_5538,

There looks to be a bug in our Docker image for 24.0.30. To work around this, if you add the environment variables PROGET_USE_HTTPS_REDIRECTION:false and PROGET_INTEGRATED_AUTHENTICATION:false to your Docker run command or Docker Compose file, that will get you passed the error for now. I have created a ticket, PG-2932, to track the fix going forward.

Thanks,
Rich