OpenSAML v4.0.1 Artifacts in Central Repository

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenSAML v4.0.1 Artifacts in Central Repository

Cris Rockwell
Hi,

I work on an open source project [0] with Apache Sling [1] that uses the OpenSAML 
v4 library. The pre-release includes the Shibboleth repository [2] in the pom.xml

We are near the point in the project where this project may be released to Maven Central 
as is common practice for all Apache Software Foundation Java artifacts.

Central has the following guidance regarding 3rd party artifacts [3]
we discourage the usage of <repositories> and <pluginRepositories> and instead 
publish any required components to the Central Repository. 
This applies for your own components as well as for 3rd party artifacts.

But I have also read the Shibboleth wiki about Maven Central [4]
So there is tension between these two recommendations.

My PMC questions whether the Shibboleth repository is needed for our project,  
because v4.0.1 is available from Central.  It came as a bit of surprise, so I’m suspicious 
about the veracity of the OpenSAML artifacts from Central, given the aforementioned 
wiki post.

As an example, the OpenSAML artifacts currently uploaded to Maven Central are not 
provided by the Shibboleth project nor are they artifacts that we've released (i.e., 
the jars out there have been changed in some unknown way).


I have started calculating the sha1 hashes for the artifacts as obtained from Maven 
Central and comparing to the hashes published to the Shibboleth repo [6]. 
So far, they indicate the artifacts contents are indeed the same. 
I may continue verifying the artifact's integrity.

Please let me know...

Has anything changed with respect to publishing artifacts to Maven Central as compared to the wiki?

Do you have any knowledge about how OpenSAML v4.0.1 artifacts were uploaded to Central in Feb 2021? 

Is it still presumed these were modified in some way as the wiki suggests?

Please let me know if you have any other suggestions.

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: OpenSAML v4.0.1 Artifacts in Central Repository

Cantor, Scott E.
On 4/23/21, 12:40 PM, "dev on behalf of Cris Rockwell" <[hidden email] on behalf of [hidden email]> wrote:

>    Has anything changed with respect to publishing artifacts to Maven Central as compared to the wiki?

No.

>    Do you have any knowledge about how OpenSAML v4.0.1 artifacts were uploaded to Central in Feb 2021?

No.

>    Is it still presumed these were modified in some way as the wiki suggests?

The only presumption is that it's impossible to know without checking, and the project's view is that if you want to compare all the artfifacts instead of just getting them from the official source, or just ostrich away the issue (what most of the planet is doing), that's really not our call.

We sign all our artifacts, so you should of course be able to tell (aside from comparing hashes) if theyr're actually the exact copies or if somebody re-signed them. Our PGP signing keys are published and we recently cleaned them up as well and fixed some weak keys.

I am gratified, somewhat, that we have been proven entirely correct; the supply chain problems with Node.js and many other systems have demonstrated these risks are not theoretical. Maven Cental is simply a bad idea if there's no well-defined provenance and no in-band signature check in all builds. That should be evident to everybody, if it wasn't before.

>    Please let me know if you have any other suggestions.

My main suggestion is that Apache needs to understand that you can't make Maven Central trustworthy simply by checking any given set of components at a given time and find that they're kosher. There is no way to sustain that state without checking every time a build happens.

We have been considering a move to a maven plugin in the build to do that using pinned keys so that we could leverage Central, but I doubt we would care to move our code there since we have no funding for supporting other people using OpenSAML, and because our belief is that the majority of projects do not "get" this issue and would not use them safely. Our contribution to that is to force people into these conversations.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: OpenSAML v4.0.1 Artifacts in Central Repository

Cris Rockwell
Hi Scott

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. 

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

     <plugin>
        <groupId>org.simplify4u.plugins</groupId>
        <artifactId>pgpverify-maven-plugin</artifactId>
        <executions>
            <execution>
                <goals>
                    <goal>check</goal>
                </goals>
            </execution>
         </executions>
      </plugin>

Seems to verify signatures for all the dependencies.

[INFO] org.springframework:spring-jcl:jar:5.2.4.RELEASE PGP Signature OK
       KeyId: 0xE2ACB037933CDEAAB7BF77D49A2C7A98E457C53D UserIds: [Spring Buildmaster <[hidden email]>]
[INFO] org.opensaml:opensaml-security-impl:jar:4.0.1 PGP Signature OK
       KeyId: 0xF4FCEFBF07F9E397A9345B9D4D37705B61CB0B3F UserIds: [Brent Putman <[hidden email]>]

Regards
Cris




On Fri, Apr 23, 2021 at 1:27 PM Cantor, Scott <[hidden email]> wrote:
On 4/23/21, 12:40 PM, "dev on behalf of Cris Rockwell" <[hidden email] on behalf of [hidden email]> wrote:

>    Has anything changed with respect to publishing artifacts to Maven Central as compared to the wiki?

No.

>    Do you have any knowledge about how OpenSAML v4.0.1 artifacts were uploaded to Central in Feb 2021?

No.

>    Is it still presumed these were modified in some way as the wiki suggests?

The only presumption is that it's impossible to know without checking, and the project's view is that if you want to compare all the artfifacts instead of just getting them from the official source, or just ostrich away the issue (what most of the planet is doing), that's really not our call.

We sign all our artifacts, so you should of course be able to tell (aside from comparing hashes) if theyr're actually the exact copies or if somebody re-signed them. Our PGP signing keys are published and we recently cleaned them up as well and fixed some weak keys.

I am gratified, somewhat, that we have been proven entirely correct; the supply chain problems with Node.js and many other systems have demonstrated these risks are not theoretical. Maven Cental is simply a bad idea if there's no well-defined provenance and no in-band signature check in all builds. That should be evident to everybody, if it wasn't before.

>    Please let me know if you have any other suggestions.

My main suggestion is that Apache needs to understand that you can't make Maven Central trustworthy simply by checking any given set of components at a given time and find that they're kosher. There is no way to sustain that state without checking every time a build happens.

We have been considering a move to a maven plugin in the build to do that using pinned keys so that we could leverage Central, but I doubt we would care to move our code there since we have no funding for supporting other people using OpenSAML, and because our belief is that the majority of projects do not "get" this issue and would not use them safely. Our contribution to that is to force people into these conversations.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: OpenSAML v4.0.1 Artifacts in Central Repository

Cantor, Scott E.
On 4/23/21, 3:43 PM, "dev on behalf of Cris Rockwell" <[hidden email] on behalf of [hidden email]> 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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 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 

[ERROR] net.shibboleth.utilities:java-support:pom:8.0.0 PGP Signature INVALID
KeyId: 0x51B52DC5DD452F92BE342CC2858FC4C4F43856A3 UserIds: [J. Daniel Kulp <[hidden email]>, J. Daniel Kulp <[hidden email]>, J. Daniel Kulp <[hidden email]>, J. Daniel Kulp <[hidden email]>, J. Daniel Kulp <[hidden email]>]

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

Thanks
Cris

On Apr 23, 2021, at 3:54 PM, Cantor, Scott <[hidden email]> wrote:

On 4/23/21, 3:43 PM, "dev on behalf of Cris Rockwell" <[hidden email] on behalf of [hidden email]> 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 [hidden email]


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: OpenSAML v4.0.1 Artifacts in Central Repository

Cantor, Scott E.
On 4/23/21, 5:54 PM, "dev on behalf of Cris Rockwell" <[hidden email] on behalf of [hidden email]> wrote:

>    After adding a plugin (pgpverify-maven-plugin) which checks dependency signatures, I have to agree.

I really don't know how "close" it is to a working solution, but last I knew we were looking into forking it and adding some features to reach a state where it might be viable.

>    The plugin provides a warning...

Right. Checking a signature means nothing unless you trust the key, which can't be "in band". And with the lack of discipline around use of PGP with software, it's a difficult thing to really rely on. Our plan was to allow this with artifacts that seemed to have disciplined key practices and probably handle the rest ourselves as we have been, but we just haven't picked it back up.

>    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?

We have *a* file, but I think we would probably be willing to go a bit farther and actually maintain such a file going forward if you're willing to give a leg up and get an initial one built.

Our keys file is here:
https://shibboleth.net/downloads/PGP_KEYS

Other than the OBS security:shibboleth RPM repository key, which wouldn't ever apply to this, that's pretty much the set.

We have a new process that generates that file now based on a git repo with the keys. If we can get a keymap to look at, I would think maybe we could extend that process to produce it. Maybe not tomorrow, but we can at least put it in the queue. The least we can do is facilitate the right practices.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: OpenSAML v4.0.1 Artifacts in Central Repository

Tom Zeller-3
> >    Do you have a list of public key fingerprints for devs that sign your artifacts?
>
>  get an initial one built.

If you have not seen this keymap, take a look :

https://github.com/s4u/pgp-keys-map/blob/master/resources/pgp-keys-map.list

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: OpenSAML v4.0.1 Artifacts in Central Repository

Tom Zeller-3
In reply to this post by Cantor, Scott E.
> We sign all our artifacts, so you should of course be able to tell (aside from comparing hashes) if theyr're actually the exact copies or if somebody re-signed them. Our PGP signing keys are published and we recently cleaned them up as well and fixed some weak keys.

The opensaml-parent-4.0.1.pom artifact in Maven Central is different
than ours and obviously does not have our signature. The
<repositories> section has been removed.

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: OpenSAML v4.0.1 Artifacts in Central Repository

Tom Zeller-3
I went ahead and submitted a ticket with Sonatype to claim ownership
of net.shibboleth and org.opensaml in Maven Central on behalf of the
Shibboleth project. --Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: OpenSAML v4.0.1 Artifacts in Central Repository

Cantor, Scott E.
On 4/26/21, 1:43 PM, "Tom Zeller" <[hidden email]> wrote:

>    I went ahead and submitted a ticket with Sonatype to claim ownership
>    of net.shibboleth and org.opensaml in Maven Central on behalf of the
>    Shibboleth project.

I'm not sure they will love the idea of us asserting the right *not* to submit artifacts to them while preventing others from doing so. I don't care either, just noting it.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: OpenSAML v4.0.1 Artifacts in Central Repository

Tom Zeller-3
> I'm not sure they will love the idea of us asserting the right *not* to submit artifacts to them while preventing others from doing so

Agree.

But the whole supply-chain safety of Maven Central depends upon us
being able to claim ownership, in fact I feel like to be proper
stewards of the internet we have to.

Tom
--
To unsubscribe from this list send an email to [hidden email]