(Adding in CC Emmanuel Lécharny <http://people.apache.org/~elecharny/>, who took a look at the proposal)
Trying to summarize our chat on Twitter, I see two outstanding points: * Emmanuel is rightly questioning/concerned about the potential of DDoS for this JEP. Tyler, should we add something about this in the JEP, or do you consider it more something to be addressed in an IEP on the infra side? (also, downstream to it AIUI, the Telemetry and other services are all DDoS vectors) * "MITM for expiry": it seems possible to reuse an UUID signed with the PK. "Ideally, to renew the token, you should have a 'nonce' to avoid MITM" @Emmanuel thanks again. If you have any other feedback, feel free to enrich or correct what I wrote you said :). Thanks everyone! 2018-03-26 17:34 GMT+02:00 R. Tyler Croy <[email protected]>: > (replies inline) > > On Mon, 26 Mar 2018, Jesse Glick wrote: > > > Jenkins already includes the `instance-identity` module, which is the > > standard mechanism¹ for both uniquely identifying a Jenkins > > installation, and permitting asymmetrically-encrypted communications > > with it. Is there a reason you are not using it? If so, that should be > > clearly documented under ???Alternative Approaches???. There is a vague > > mention of OpenSSH keys, but this module is not limited to SSH (much > > less OpenSSH), and public-key encryption has widespread library > > support. > > > Thanks for taking a look Jesse! You're right that Jenkins already does > have an > instance identity floating around. In a much earlier iteration of my > thinking I was > considering using this until I started to think about how this would work > in > practice for new installations. > > Unfortunately when the jenkins/evergreen image comes online and checks for > updates, it will not have run `jenkins.war` at all yet, and therefore no > instance identity. Rather than have one unprotected/identified route in the > service backend for bootstrapping new nodes, I am erring on the side of > treating all "got updates?" requests the same, which requires a client > registration and identity to kick the process off. > > You're absolutely right that the 'Alternative Approaches" section doesn't > list > this and should, I'll update shortly. > > > > Cheers > - R. Tyler Croy > > ------------------------------------------------------ > Code: <https://github.com/rtyler> > Chatter: <https://twitter.com/agentdero> > xmpp: [email protected] > > % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F > ------------------------------------------------------ > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ms > gid/jenkinsci-dev/20180326153407.5on7xn7gdl7odfue%40blackber > ry.coupleofllamas.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4e7JLGTSvqzqBJMQp_YMwKwQ-KFm-cEZnR9Djz0UWfHA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
