[Pki-devel] [CRON] Still Failing: dogtagpki/pki-nightly-test#553 (master - 7d8d351)
Build Update for dogtagpki/pki-nightly-test - Build: #553 Status: Still Failing Duration: 18 mins and 21 secs Commit: 7d8d351 (master) Author: Dinesh Prasanth M K Message: Fix jobs to include beta/rawhide as optional jobs Signed-off-by: Dinesh Prasanth M K View the changeset: https://github.com/dogtagpki/pki-nightly-test/compare/f9b30e4c74c812bd0414a2f5282f1153a7776df1...7d8d351192b013988a4667ee2dd16892d47291ff View the full build log and details: https://travis-ci.org/dogtagpki/pki-nightly-test/builds/620995463?utm_medium=notification_source=email -- You can unsubscribe from build emails from the dogtagpki/pki-nightly-test repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=20325727_medium=notification_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [acme] getOrderByAuthorization() / orders and authorisations
On Thu, Dec 05, 2019 at 11:18:15AM +1000, Fraser Tweedale wrote: > On Wed, Dec 04, 2019 at 06:36:24PM -0500, Endi Sukma Dewata wrote: > > - Original Message - > > > Just want to flag something related to ACME orders and > > > authorisations. > > > > > > In ACME authorizations can be shared by multiple orders. In fact > > > you can also "preauthorize" your account for an identifier, so there > > > can also be a authorizations with no orders attached. > > > > > > Does the way we have implemented the ACME service ensure that an > > > authorization has only one order (or at most one order)? If so, do > > > we want it that way? It entails that every identifier must be > > > re-authorised upon every order. > > > > > > Personally I think this is not the way we want to go. Let me > > > describe a scenario. > > > > > > Client orders a cert for a.example.com, completes the authorisation > > > for a.example.com, and gets the cert. > > > > > > Shortly afterwards, they realise they also need b.example.com on the > > > certificate. So they make a new order with BOTH identifiers. > > > > > > Should the client have to complete another authorisation for > > > a.example.com, while their existing authorisation remains "fresh" > > > (unexpired)? It is valid to require the client to re-authorise > > > every identifier for every order. But it is not optimal. Ideally > > > we should observe that for the account there is already a > > > non-expired authorisation for "a.example.com", and attach that to > > > the order (along with the new authorisation for "b.example.com" > > > which the client must complete). > > > > > > Anyhow just some ideas as I proceed with implementation of the LDAP > > > database implement. Let me know your thoughts. > > > > I think you're right. The database schema itself is not limiting to > > one order per authorization, but the current code is making that > > assumption. > > > > We could change getOrderByAuthorization() to getOrdersByAuthorization(), > > then move this code into a loop to process all orders associated to > > that authorization: > > https://github.com/dogtagpki/pki/blob/master/base/acme/src/org/dogtagpki/acme/server/ACMEChallengeService.java#L124-L144 > > > > If we want to reuse existing authorizations, we will need to modify this > > code to find an existing authorization that is still valid instead of > > creating a new one: > > https://github.com/dogtagpki/pki/blob/master/base/acme/src/org/dogtagpki/acme/server/ACMENewOrderService.java#L72-L83 > > > OK, I'll file a ticket now and we can come back to it later. > Ticket is https://projects.engineering.redhat.com/browse/RHCS-814, part of the RHCS-35 epic. Cheers, Fraser ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] [acme] getOrderByAuthorization() / orders and authorisations
- Original Message - > Just want to flag something related to ACME orders and > authorisations. > > In ACME authorizations can be shared by multiple orders. In fact > you can also "preauthorize" your account for an identifier, so there > can also be a authorizations with no orders attached. > > Does the way we have implemented the ACME service ensure that an > authorization has only one order (or at most one order)? If so, do > we want it that way? It entails that every identifier must be > re-authorised upon every order. > > Personally I think this is not the way we want to go. Let me > describe a scenario. > > Client orders a cert for a.example.com, completes the authorisation > for a.example.com, and gets the cert. > > Shortly afterwards, they realise they also need b.example.com on the > certificate. So they make a new order with BOTH identifiers. > > Should the client have to complete another authorisation for > a.example.com, while their existing authorisation remains "fresh" > (unexpired)? It is valid to require the client to re-authorise > every identifier for every order. But it is not optimal. Ideally > we should observe that for the account there is already a > non-expired authorisation for "a.example.com", and attach that to > the order (along with the new authorisation for "b.example.com" > which the client must complete). > > Anyhow just some ideas as I proceed with implementation of the LDAP > database implement. Let me know your thoughts. I think you're right. The database schema itself is not limiting to one order per authorization, but the current code is making that assumption. We could change getOrderByAuthorization() to getOrdersByAuthorization(), then move this code into a loop to process all orders associated to that authorization: https://github.com/dogtagpki/pki/blob/master/base/acme/src/org/dogtagpki/acme/server/ACMEChallengeService.java#L124-L144 If we want to reuse existing authorizations, we will need to modify this code to find an existing authorization that is still valid instead of creating a new one: https://github.com/dogtagpki/pki/blob/master/base/acme/src/org/dogtagpki/acme/server/ACMENewOrderService.java#L72-L83 -- Endi S. Dewata ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
[Pki-devel] [acme] getOrderByAuthorization() / orders and authorisations
Just want to flag something related to ACME orders and authorisations. In ACME authorizations can be shared by multiple orders. In fact you can also "preauthorize" your account for an identifier, so there can also be a authorizations with no orders attached. Does the way we have implemented the ACME service ensure that an authorization has only one order (or at most one order)? If so, do we want it that way? It entails that every identifier must be re-authorised upon every order. Personally I think this is not the way we want to go. Let me describe a scenario. Client orders a cert for a.example.com, completes the authorisation for a.example.com, and gets the cert. Shortly afterwards, they realise they also need b.example.com on the certificate. So they make a new order with BOTH identifiers. Should the client have to complete another authorisation for a.example.com, while their existing authorisation remains "fresh" (unexpired)? It is valid to require the client to re-authorise every identifier for every order. But it is not optimal. Ideally we should observe that for the account there is already a non-expired authorisation for "a.example.com", and attach that to the order (along with the new authorisation for "b.example.com" which the client must complete). Anyhow just some ideas as I proceed with implementation of the LDAP database implement. Let me know your thoughts. Cheers, Fraser ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
