inedo-engineer group

stevedennis

Just to give you some more technical context, which you probably already figured out...

The "old" vulnerability model worked by downloading a datafile from security.inedo.com, unpacking it, and inserting rows in the PgvdVulnerabilities and PgvdPackageNames tables. Those tables contained every vulnerability in our database and it was a bit tricky to know which of those vulnerabilities related to package versions "in" ProGet. The PgvdAssessments table helped somewhat.

The "new" model works by downloading an indexed database file. The "Assess Vulnerabilities" function (which rurns on that download job as well) will iterate over all vulnerabilities in that database and adds/removes rows to the PgvdVulnerabilities26 tables as needed (including PgvdPackageVersions), which makes it much easier to know if a vulnerability impacts a version "in" ProGet by looking at the database.

There are most certainly edge cases and glitches in this, so don't hesitate to let us know if you spot any odd behavior.

Thanks,
Steve

dean-houston

Hi @Nils-Nilsson ,

That message appears to be coming from SetCommand.cs#L91... is it possible you're not on the latest pgutil (i.e. 2.4.2)?

That would be my guess...

-- Dean

stevedennis

Hi @caterina,

It's quite complicated and there are a lot of technical details that I'm not immediately familiar with. To properly answer, I'd need to set up a reproduction case and then attach a debugger to give you a more technically precise answer on why it's displaying that way.

We may even need to do a whole database backup, since it might be specific to your configuration. I really don't know how much of an investigation it would require.

We added the dotted line as primarily a way for us to identify the system state when there are issues reported. Previous version of ProGet also had provisional assessments, but it was never visually indicated.

Anyway, if you're seeing any problems jut let us know -- this shouldn't have any impact outside of the dotted-line display on some pages.

Thanks,
Steve

stevedennis

Hi @caterina ,

The dotted border indicates what we call a provisional assessment; we don't have a great description for what that means, but that's what you'll see when a package is not local or cached in ProGet.

Without getting into too many technical details, that's the expected behavior (i.e. not in the database, not on the SCA > Vulnerabilities page). Once the Vulnerability Download job (or Admin > Vuln Types > Reassess) runs, it should become a normal assessment (i.e. show in the database, etc).

In any case, whether an assessment is provisional or not shouldn't have any impact on compliance analysis. The most notable impact is that it won't show up on the SCA > Vulnerabilities page until another job identifies the package as being "in" ProGet.

Thanks,
Steve

atripp

@Nils-Nilsson thank you so much!

We've published a new version of pgutil with these commands added :)

atripp

Hi @bobmaurer ,

We recommend to import those packages into ProGet and publish to ProGet going forward.

That keeps ProGet as the source of truth for your artifacts, reduces a lot of network traffic, makes it easier for developers to not worry about multiple sources, and eliminates a lot of possible headaches later with configuration/outages/authentication./etc. Much simpler this way.

Best,
Alana

dean-houston

Hi @dan.brown_0128 ,

Here's our current position on MCP Registries:

From a quick read of the documentation, it looks like an "MCP Registry" is mostly just a JSON document that lists "MCP Servers". There don't seem to be "Packages" (i.e. an archive file with a manifest file) nor a "Central Repository" (i.e. a canonical location where OSS Models are stored), which means it's not a great fit for ProGet.

Here's the current discussion on the topic: Request to support MCP registry; I'd encourage you to add your thoughts to that!

-- Dean

apxltd

Thanks @sigurd.hansen_7559 !

All right, I'm convinced.... this makes a lot more sense now to do now! I didn't quite realize that Microsoft does not allow non-VSCode clients to connect to their Marketplace, nor did I realize there were so many VSCode forks.

The current plan is to create a new feed type called "Open VSIX" or something that will support connectors. It should also be able to handle the "multi-file packages" (i.e. how the same extension can have multiple .vsix files but different architectures).

We should be able to just reverse engineer the VSIX API as well. That's clearly Open VSIX did; it's not all that complex I think. I've just now updated the other feed types; we don't have a date just yet, but it should e in the coming months. We'll keep this thread up to date.

dean-houston

Hi @jimbobmcgee ,

Long story short, "we're not entirely sure anymore."

You've picked up on the original intent: these are intended to provide UI-based inputs around script parameters. And they do "mostly" show up in the use case you identify (i.e. when creating a Job Template for the first time)... but they are overall a glitchy feature.

They were also intended to allow for Param()-like support to other scripting languages, so you'd simply need to add that header to the script and it would just "work" in OtterScript and job templates.

From an engineering standpoint, we had planned to improve all of these after Otter 2022 (when they were first released), but our R&D priorities suddenly shifted. So we haven't had time to revisit them (or other Otter features we wanted to do), and they're basically in that same glitchy state

Personally I thought they were a pretty neat idea, and it's just unfortunate we weren't able to take them further. But, so it goes with development priorities...

-- Dean

dean-houston

Hi @amy.j ,

Looks like the code was actually merged in and shipped, but that status wasn't reflected on the YouTrack issue, so the note didn't get added to the release.

Anyway I've modified the status and manually updated the release notes now.

-- Dean

inedo-engineer

Posts

Member List