OpenSAML v4.0.1 Artifacts in Central Repository

[Cris Rockwell]

Hi Scott

After adding a plugin (pgpverify-maven-plugin) which checks dependency
signatures, I have to agree.
The build failed when due to invalid dependency signatures
https://ci-builds.apache.org/blue/organizations/jenkins/Sling%2Fmodules%2Fsling-org-apache-sling-auth-saml2/detail/PR-1/2/pipeline

[ERROR] net.shibboleth.utilities:java-support:pom:8.0.0 PGP Signature
INVALID
KeyId: 0x51B52DC5DD452F92BE342CC2858FC4C4F43856A3 UserIds: [J. Daniel Kulp <
dan at kulp.com>, J. Daniel Kulp <dkulp at apache.org>, J. Daniel Kulp <
dkulp at progress.com>, J. Daniel Kulp <dkulp at talend.com>, J. Daniel Kulp <
dan.kulp at sopera.com>]

It's clear that having both the shib repo and signature validation are
valuable. I can make that case to the project committee.

The plugin provides a warning...
No keysmap specified in configuration or keysmap contains no entries.
PGPVerify will only check artifacts against their signature. File
corruption will be detected. However, without a keysmap as a reference for
trust, valid signatures of any public key will be accepted.

So, I would actually like to provide a key mapping for the OpenSAML library
and clear that warning.

Do you have a list of public key fingerprints for devs that sign your
artifacts?
I would like to build this file
https://www.simplify4u.org/pgpverify-maven-plugin/keysmap-format.html

Thanks
Cris

On Apr 23, 2021, at 3:54 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

On 4/23/21, 3:43 PM, "dev on behalf of Cris Rockwell" <
dev-bounces at shibboleth.net on behalf of cmrockwe at umich.edu> wrote:

  It's a super valuable conversation. You are absolutely right about the
need to defend against supply attacks.In
terms of what "Apache needs to understand," I hope I didn't give the wrong
impression.
After all, I am just an individual committer to one of their projects.


Yes, but ultimately you have a voice there and I don't, and you engaged and
they didn't, so I'm just making the case for why we have a problem with how
Central is used. Putting our artifacts there just doesn't end up getting
people to do the right thing, so we don't.

  What I think might work is adding this plugin to our project build


There are a lot of complexities that go into it, and my understanding is
that no existing plugin "just works" to do this correctly but honestly...I
haven't kept up and we haven't picked up the thread here to look at it
lately so I don't know what state it's in.

But yes, that's the general idea.

  Seems to verify signatures for all the dependencies.


And the latter one is ours, yes.

An issue with using Central fundamentally is that we are not putting
anything there and we don't update it when we release new versions,
including security releases.

I think the PMC is misguided in their philosophy and don't believe that
"one place to get everything" is a workable model for anything, and that
applies as much or more to GitHub, which has become just as bad. But that
said, if their argument is that they have no reason to trust our repo, I
can accept that except for the part where they're trusting one that's
self-evidently not trustworthy (e.g., our artifacts are there, nobody but
us has the "right" to put them there, yet they're there, ergo Central's
model is fatally flawed).

-- Scott


-- 
To unsubscribe from this list send an email to
dev-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20210423/e5556398/attachment-0001.htm>