What severity do you think we should attribute to this? My early guess is medium, but wanted to gather some thoughts on it

yes, medium is good.

@monperrus what's the idea here, exactly? If any commit present in the commit history up until the release point isn't signed, we flag it?

My concern with flagging signatures (and this may be a dumb thought) is this: think about scenarios where you have a PR, which may have unsigned commits, and then a maintainer merges the PR; even if that maintainer signs the merge commit -- which should be what matters -- the other commits would be merged too (unless it's a squash), and that could lead to flagging code that, where it matters, is signed. I also don't think there's a good way to programmatically "ignore commits if they're coming from a PR which was merged".

Do you see where I'm getting at it/do you agree with my sentiment here? I may be overthinking

There are commit signatures and release signatures.
Here, we refer to release signatures.
https://repo1.maven.org/maven2/fr/inria/gforge/spoon/spoon-core/11.1.1-beta-9/spoon-core-11.1.1-beta-9-jar-with-dependencies.jar.asc

For NPM:
https://docs.npmjs.com/verifying-registry-signatures

@algomaster99 out of curiosity, do you know of any projects where testing for code signature would provide valuable results? Because atm my code at the code-signature branch doesn't find any missing code signatures in spoon nor in StoyanTc/yammer-metrics - v3.0.1, and I'd like to confirm whether the tool was correctly working or not

testing for code signature would provide valuable results

What do you mean by valuable here?

In Java ecosystem, all maven releases on Central repository must confirm to some requirements. One of them is that all files that are pushed for deployment must be signed with gpg keys. However, there are several repositories where these requirements won't be enforced and there you may find some "no code signatures".

What do you mean by valuable here?
I meant repos where, for one reason or another, it's known that, if we ran the tool, we'd find dependencies which aren't signed.

I didn't know that in the central repository it was a requirement to sign the code, that's nice to know! I'd say that this makes this check a bit less relevant then, but still, since packages might be in other repos which aren't the central one, it's probably worthwhile to keep it, right?

might be in other repos which aren't the central one, it's probably worthwhile to keep it, right?

Exactly, that is my intuition as well. Although I have never come across such a repository. Let me as Hérve.
Also, @randomicecube I linked the wrong URL to requirements. I have updated it. Please check.

@hboutemy, do you know if these requirements are only for Central repository in mvnrepository.com or it is for all repositories?

these requirements are for Maven Central only: other repositories may choose to reuse, but it's their choice to do or not to do (and implement checks if they don't have a centralized publication pipeline)

notice: mvnrepository is only a search engine, scraping as many repositories as they can, and consolidating indexes to provide consolidated search.

Each repository scraped by mvnrepository is managed by independent entities that do what they want with their content.

Maven Central has published rules and checks them, with most importantly namespace ownership https://central.sonatype.org/publish/requirements/coordinates/ and immutability https://central.sonatype.org/publish/requirements/immutability/

What do others do? I don't know: one consuming from them should ask them, because de-facto they trust them, and they trust them on any coordinates...