Date   

Re: LDAP Annotation and Database Hashing Proposal

Arjan Tijms
 

Hi,

On Sat, Jul 22, 2017 at 10:06 PM, Will Hopkins <will.hopkins@...> wrote:
Arjan, et al.:

I've pushed some changes to the hashalgorithm branch in both security-api and security-soteria; please have a look to see what you think.
  • I considered PasswordHashAlgorithm, but that seemed too long, especially for interfaces/classes that would extend it. 


"PasswordHashAlgorithm" certainly doesn't feel too long for me.
 
  • Also renamed IdentityHashAlgorithm to PlaintextPasswordHash.

Ok 
  • Added generateHash() method.

Ok 
  • Removed hash parameters passed to verifyHash(). I did not remove the DatabaseIdentityStoreDefinition hashProperties attribute, nor did I remove the "plumbing" that passees the properties down to the hash implementation, in case we want to restore the properties. But they are not currently passed in to the PasswordHash.

Even if the standard Pbkdf2PasswordHashImpl doesn't use it, I think it doesn't hurt much to pass them in anyway.
 
  • Implemented a (more or less) constant time compare for passwords/hashes, and updated the two PasswordHash impl classes to use it.
  • Re-wrote Pbkdf2PasswordHashImpl to:
    • Generate hashes with a specific storage format (encoding), and parse that encoding when doing verifyHash(), such that the verify operation can use the algorithm/parameters/salt that were used to hash the password originally, instead of the currently configured paramters.
    • Added support for multiple flavors of PBKDF2 (i.e., "with" different Hmac algorithms). Now supports all SHA1/2 variants, but not MD5 (which doesn't appear to be available, or at least not enabled by default, in JDK8).
    • Changed the default parameters to be more in line with current best practices.

Ok
 
So, this is what I had in mind. It's really not so different from what you coded up, Arjan, except for some of the algorithm implementation details, the lack of properties support, and the flexible encoding format that allows default parameters to be changed while preserving the ability to verify passwords hashed with different parameters.

My reasoning behind removing the properties support is as follows:
  • The application developer already has complete control because he/she can provide a custom algorithm to meet any requirement. Properties may be convenient in some cases, but even without them the developer can do whatever they need to do.
  • We are already introducing a very large change after PFD publication. Properties mean more to specify and document, and, more crucially, they mean more test assertions and TCK test cases to write. There is already concern internally about our ability to complete the TCK on schedule.

Ok
 
  • As is hopefully made more clear by my implementation code, the algorithm itself, and related parameters, are not really the source of most variation and complexity for password hashes -- it's the content and format of the encoded hashed password, as stored in the database, that seems likely to be infinitely more variable. There are likely a number of fairly common formats, but I suspect most are ad hoc, and practices are changing rapidly over time. In any event, we simply don't have time to research that question to figure out if there are any formats common enough to standardize on. (Nor do we have time to develop and implement some kind of expression syntax to specifies what the encoding should look like.)

As I mentioned, the encoding step is very likely common enough to warrant having its own method in the interface, so developers can e.g. decorate the default algorithm and only change the encoding.

 
As a result, I think it's highly unlikely that the ability to supply properties is going to be enough to allow developers to customize everything they'll want or need to

Like the entire concept of the DatabaseIdentityStore, it's indeed unlikely to ever cover everything everyone ever wants, but the 80% rule comes in play here; it's okay if we design for the 80% and then the 20% can do whatever they want in a custom implementation.

I personally still feel parameters with reasonable defaults are still a good intermediate solution between using the standard algorithm as is, and having to write something from scratch.

That said, if there's no time, there's no time. Or in other words, it is what it is ;)

Kind regards,
Arjan Tijms


 
, even when they're creating a new identity store and have complete control over the format. In the case that they need to develop for an existing identity store, with existing password hash formats, the chances are close to zero that a generic password hash implementation could be adequately customized with properties.
With all of that in mind, I do think properties are a nice feature, but they don't seem absolutely necessary -- developers have full control without them -- and it's not clear they'd really be useful in very many scenarios. I suspect they would mostly be used to fiddle with parameters in cases where the default storage encoding is deemed to be acceptable, and that, in most cases, the default algorithm/parameters would probably be deemed acceptable as well, if properties weren't available. As such, I'm reluctant to take on the extra complexity and work required to support properties at this point.

Anyway, that's my proposal. Thoughts?

Will


On 07/20/2017 03:25 PM, Arjan Tijms wrote:
Hi,

The adaptability concern is basically the main concern of the entire DataBaseIdentityStore. Indeed, having a query to get the (hashed) password from the caller name and another to get the groups covers maybe 80% of use cases, but certainly not all.

There are for instance exotic database schemes were you'd need at least 2 seperate queries to get that data.

For the hash algorithm the same thing holds. We need to specify enough moving parts so we can adapt to *many* existing databases and requirements, but we shouldn't even be dreaming about covering them all.

Since parameters can contain EL as values as well, it wouldn't be crazy hard really to supply the encoding as a method expression. It's basically a byte[] -> String function.

In this case though I think encoding is a general enough moving part to warrant its own method in the interface. It can easily be defaulted to e.g. base64 and it can be overridden without exposing the implementation by use of a CDI decorator (or should be after we solve a bug or problem that currently prevents decorating).

Kind regards,
Arjan Tijms


On Thursday, July 20, 2017, Will Hopkins <will.hopkins@...> wrote:


On 07/20/2017 12:38 PM, Guillermo González de Agüero wrote:


Similarly, parameters like the salt and iteration count can be defaulted. That way you can have 3 levels:

1. Specify only the class name; you get defaults for all parameters and it Just Works
2. Specify the parameters locally to match a specific DB or requirement
3. (via EL) fetch the parameter values externally

The most important rule should always be that the developer is in full control, or can be in full control. External overrides should be possible, but never be required. That is -the- big mistake that Java EE made in the past.
I agree, but I think we're only talking about what the mechanism for override is, and what the trade-off between simplicity and the override mechanism is. In practice, I don't think parameters are going to be very helpful to most developers. They can be used to tweak some simple things, but the simple things won't typically be necessary and the more complex things can't be handled by parameters.
 
Could you please provide an example of such a setting, please? Just to better understand. Otherwise, we could just wait for your new proposal to see.

Basically, it's the encoding of the hashed password. Parameters like salt, iterations, hash key size, etc. are all pretty standard. They can be dialed up or dialed down to make the hash stronger or weaker, and I think "stronger vs. weaker" is the level at which most people think about them. I doubt many developers are concerned about specifying precisely a certain number of iterations for some reason, they just want iterations count to be high enough to be secure, without imposing excessive overhead or resource consumption, and security most often wins out vs. resource consumption these days. Most will be happy if they can turn up the volume with a single knob, they don't need bass and treble and balance knobs. Even better: if the default volume is about right, and if the volume automatically goes up when you're driving at higher speeds.

In contrast, the format of the encoded string is not standard in any way that I'm aware of. There are probably LDAP vendors that do things in a common way, but for any given database user store, either the format has already been decided, because there are existing user accounts, or the developer won't care as long as the default format is reasonable (assuming the DB schema allows enough space for the chosen encoding format.

I can't think of any good way to standardize parameters to describe how the hashed password is encoded for storage, and that's the hard part, the part that you really have to adapt to. It's not a big deal if you have to use 4000 iterations instead of 2000, but it's a big deal if you can't parse the encoded password. And since the encoding is completely arbitrary and non-standard, that's the real problem, and that's what will likely force people to do their own implementation of HashAlgorithm. That can't be specified as Properties.

We could probably come up with an interface for encoding/decoding the hashed value, or for describing the encoded value as a string and passing it as a property. But that's a lot to spec out, and we just don't have time for it. It's complicated by the fact that decoding a hash potentially yields all the parameters that were used to generate the hash, so there'd need to be a generalized interface for returning those in a standard way. Plus, in some databases, the encodings used will vary, as legacy hashes are replaced with stronger hashes/different encodings when people change their password.

It's hard to argue against supplying Properties. It's not difficult to implement, and it might be useful. But I'm trying to keep the interface as simple as possible -- in part to reduce the number of additional TCK tests that need to be written -- and I suspect the Properties will rarely be useful. Some people will want to use them, but for many the defaults will be good enough, and many of those with specific requirements will already be forced to write an implementation in order to deal with encoding issues.

Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803



Re: LDAP Annotation and Database Hashing Proposal

Guillermo González de Agüero
 

Thanks Will!

I imagine your changes are on the https://github.com/javaee/security-soteria/tree/hashalgorithm branch, no? Could you please create a pull request to master? That simplifies reviewing the changes of all commits at once and also will trigger notifications for repository watchers.

I'll take a look at it tomorrow and come back with some feedback.


Regards,

Guillermo González de Agüero


El sáb., 22 de julio de 2017 22:06, Will Hopkins <will.hopkins@...> escribió:
Arjan, et al.:

I've pushed some changes to the hashalgorithm branch in both security-api and security-soteria; please have a look to see what you think.
  • One change was a rename of the interface from HashAlgorithm to PasswordHash, to be more explicit/accurate about what the interface is for -- it's specific to passwords, which is very distinct from regular cryptographic hashing. I considered PasswordHashAlgorithm, but that seemed too long, especially for interfaces/classes that would extend it. Willing to reconsider the name, but if others have strong feelings.
  • Also renamed IdentityHashAlgorithm to PlaintextPasswordHash.
  • Added generateHash() method.
  • Removed hash parameters passed to verifyHash(). I did not remove the DatabaseIdentityStoreDefinition hashProperties attribute, nor did I remove the "plumbing" that passees the properties down to the hash implementation, in case we want to restore the properties. But they are not currently passed in to the PasswordHash.
  • Implemented a (more or less) constant time compare for passwords/hashes, and updated the two PasswordHash impl classes to use it.
  • Re-wrote Pbkdf2PasswordHashImpl to:
    • Generate hashes with a specific storage format (encoding), and parse that encoding when doing verifyHash(), such that the verify operation can use the algorithm/parameters/salt that were used to hash the password originally, instead of the currently configured paramters.
    • Added support for multiple flavors of PBKDF2 (i.e., "with" different Hmac algorithms). Now supports all SHA1/2 variants, but not MD5 (which doesn't appear to be available, or at least not enabled by default, in JDK8).
    • Changed the default parameters to be more in line with current best practices.
So, this is what I had in mind. It's really not so different from what you coded up, Arjan, except for some of the algorithm implementation details, the lack of properties support, and the flexible encoding format that allows default parameters to be changed while preserving the ability to verify passwords hashed with different parameters.

My reasoning behind removing the properties support is as follows:
  • The application developer already has complete control because he/she can provide a custom algorithm to meet any requirement. Properties may be convenient in some cases, but even without them the developer can do whatever they need to do.
  • We are already introducing a very large change after PFD publication. Properties mean more to specify and document, and, more crucially, they mean more test assertions and TCK test cases to write. There is already concern internally about our ability to complete the TCK on schedule.
  • As is hopefully made more clear by my implementation code, the algorithm itself, and related parameters, are not really the source of most variation and complexity for password hashes -- it's the content and format of the encoded hashed password, as stored in the database, that seems likely to be infinitely more variable. There are likely a number of fairly common formats, but I suspect most are ad hoc, and practices are changing rapidly over time. In any event, we simply don't have time to research that question to figure out if there are any formats common enough to standardize on. (Nor do we have time to develop and implement some kind of expression syntax to specifies what the encoding should look like.)
As a result, I think it's highly unlikely that the ability to supply properties is going to be enough to allow developers to customize everything they'll want or need to, even when they're creating a new identity store and have complete control over the format. In the case that they need to develop for an existing identity store, with existing password hash formats, the chances are close to zero that a generic password hash implementation could be adequately customized with properties.
With all of that in mind, I do think properties are a nice feature, but they don't seem absolutely necessary -- developers have full control without them -- and it's not clear they'd really be useful in very many scenarios. I suspect they would mostly be used to fiddle with parameters in cases where the default storage encoding is deemed to be acceptable, and that, in most cases, the default algorithm/parameters would probably be deemed acceptable as well, if properties weren't available. As such, I'm reluctant to take on the extra complexity and work required to support properties at this point.

Anyway, that's my proposal. Thoughts?

Will


On 07/20/2017 03:25 PM, Arjan Tijms wrote:
Hi,

The adaptability concern is basically the main concern of the entire DataBaseIdentityStore. Indeed, having a query to get the (hashed) password from the caller name and another to get the groups covers maybe 80% of use cases, but certainly not all.

There are for instance exotic database schemes were you'd need at least 2 seperate queries to get that data.

For the hash algorithm the same thing holds. We need to specify enough moving parts so we can adapt to *many* existing databases and requirements, but we shouldn't even be dreaming about covering them all.

Since parameters can contain EL as values as well, it wouldn't be crazy hard really to supply the encoding as a method expression. It's basically a byte[] -> String function.

In this case though I think encoding is a general enough moving part to warrant its own method in the interface. It can easily be defaulted to e.g. base64 and it can be overridden without exposing the implementation by use of a CDI decorator (or should be after we solve a bug or problem that currently prevents decorating).

Kind regards,
Arjan Tijms


On Thursday, July 20, 2017, Will Hopkins <will.hopkins@...> wrote:


On 07/20/2017 12:38 PM, Guillermo González de Agüero wrote:


Similarly, parameters like the salt and iteration count can be defaulted. That way you can have 3 levels:

1. Specify only the class name; you get defaults for all parameters and it Just Works
2. Specify the parameters locally to match a specific DB or requirement
3. (via EL) fetch the parameter values externally

The most important rule should always be that the developer is in full control, or can be in full control. External overrides should be possible, but never be required. That is -the- big mistake that Java EE made in the past.
I agree, but I think we're only talking about what the mechanism for override is, and what the trade-off between simplicity and the override mechanism is. In practice, I don't think parameters are going to be very helpful to most developers. They can be used to tweak some simple things, but the simple things won't typically be necessary and the more complex things can't be handled by parameters.
 
Could you please provide an example of such a setting, please? Just to better understand. Otherwise, we could just wait for your new proposal to see.

Basically, it's the encoding of the hashed password. Parameters like salt, iterations, hash key size, etc. are all pretty standard. They can be dialed up or dialed down to make the hash stronger or weaker, and I think "stronger vs. weaker" is the level at which most people think about them. I doubt many developers are concerned about specifying precisely a certain number of iterations for some reason, they just want iterations count to be high enough to be secure, without imposing excessive overhead or resource consumption, and security most often wins out vs. resource consumption these days. Most will be happy if they can turn up the volume with a single knob, they don't need bass and treble and balance knobs. Even better: if the default volume is about right, and if the volume automatically goes up when you're driving at higher speeds.

In contrast, the format of the encoded string is not standard in any way that I'm aware of. There are probably LDAP vendors that do things in a common way, but for any given database user store, either the format has already been decided, because there are existing user accounts, or the developer won't care as long as the default format is reasonable (assuming the DB schema allows enough space for the chosen encoding format.

I can't think of any good way to standardize parameters to describe how the hashed password is encoded for storage, and that's the hard part, the part that you really have to adapt to. It's not a big deal if you have to use 4000 iterations instead of 2000, but it's a big deal if you can't parse the encoded password. And since the encoding is completely arbitrary and non-standard, that's the real problem, and that's what will likely force people to do their own implementation of HashAlgorithm. That can't be specified as Properties.

We could probably come up with an interface for encoding/decoding the hashed value, or for describing the encoded value as a string and passing it as a property. But that's a lot to spec out, and we just don't have time for it. It's complicated by the fact that decoding a hash potentially yields all the parameters that were used to generate the hash, so there'd need to be a generalized interface for returning those in a standard way. Plus, in some databases, the encodings used will vary, as legacy hashes are replaced with stronger hashes/different encodings when people change their password.

It's hard to argue against supplying Properties. It's not difficult to implement, and it might be useful. But I'm trying to keep the interface as simple as possible -- in part to reduce the number of additional TCK tests that need to be written -- and I suspect the Properties will rarely be useful. Some people will want to use them, but for many the defaults will be good enough, and many of those with specific requirements will already be forced to write an implementation in order to deal with encoding issues.

Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Re: LDAP Annotation and Database Hashing Proposal

Will Hopkins
 

Arjan, et al.:

I've pushed some changes to the hashalgorithm branch in both security-api and security-soteria; please have a look to see what you think.
  • One change was a rename of the interface from HashAlgorithm to PasswordHash, to be more explicit/accurate about what the interface is for -- it's specific to passwords, which is very distinct from regular cryptographic hashing. I considered PasswordHashAlgorithm, but that seemed too long, especially for interfaces/classes that would extend it. Willing to reconsider the name, but if others have strong feelings.
  • Also renamed IdentityHashAlgorithm to PlaintextPasswordHash.
  • Added generateHash() method.
  • Removed hash parameters passed to verifyHash(). I did not remove the DatabaseIdentityStoreDefinition hashProperties attribute, nor did I remove the "plumbing" that passees the properties down to the hash implementation, in case we want to restore the properties. But they are not currently passed in to the PasswordHash.
  • Implemented a (more or less) constant time compare for passwords/hashes, and updated the two PasswordHash impl classes to use it.
  • Re-wrote Pbkdf2PasswordHashImpl to:
    • Generate hashes with a specific storage format (encoding), and parse that encoding when doing verifyHash(), such that the verify operation can use the algorithm/parameters/salt that were used to hash the password originally, instead of the currently configured paramters.
    • Added support for multiple flavors of PBKDF2 (i.e., "with" different Hmac algorithms). Now supports all SHA1/2 variants, but not MD5 (which doesn't appear to be available, or at least not enabled by default, in JDK8).
    • Changed the default parameters to be more in line with current best practices.
So, this is what I had in mind. It's really not so different from what you coded up, Arjan, except for some of the algorithm implementation details, the lack of properties support, and the flexible encoding format that allows default parameters to be changed while preserving the ability to verify passwords hashed with different parameters.

My reasoning behind removing the properties support is as follows:
  • The application developer already has complete control because he/she can provide a custom algorithm to meet any requirement. Properties may be convenient in some cases, but even without them the developer can do whatever they need to do.
  • We are already introducing a very large change after PFD publication. Properties mean more to specify and document, and, more crucially, they mean more test assertions and TCK test cases to write. There is already concern internally about our ability to complete the TCK on schedule.
  • As is hopefully made more clear by my implementation code, the algorithm itself, and related parameters, are not really the source of most variation and complexity for password hashes -- it's the content and format of the encoded hashed password, as stored in the database, that seems likely to be infinitely more variable. There are likely a number of fairly common formats, but I suspect most are ad hoc, and practices are changing rapidly over time. In any event, we simply don't have time to research that question to figure out if there are any formats common enough to standardize on. (Nor do we have time to develop and implement some kind of expression syntax to specifies what the encoding should look like.)
As a result, I think it's highly unlikely that the ability to supply properties is going to be enough to allow developers to customize everything they'll want or need to, even when they're creating a new identity store and have complete control over the format. In the case that they need to develop for an existing identity store, with existing password hash formats, the chances are close to zero that a generic password hash implementation could be adequately customized with properties.
With all of that in mind, I do think properties are a nice feature, but they don't seem absolutely necessary -- developers have full control without them -- and it's not clear they'd really be useful in very many scenarios. I suspect they would mostly be used to fiddle with parameters in cases where the default storage encoding is deemed to be acceptable, and that, in most cases, the default algorithm/parameters would probably be deemed acceptable as well, if properties weren't available. As such, I'm reluctant to take on the extra complexity and work required to support properties at this point.

Anyway, that's my proposal. Thoughts?

Will

On 07/20/2017 03:25 PM, Arjan Tijms wrote:
Hi,

The adaptability concern is basically the main concern of the entire DataBaseIdentityStore. Indeed, having a query to get the (hashed) password from the caller name and another to get the groups covers maybe 80% of use cases, but certainly not all.

There are for instance exotic database schemes were you'd need at least 2 seperate queries to get that data.

For the hash algorithm the same thing holds. We need to specify enough moving parts so we can adapt to *many* existing databases and requirements, but we shouldn't even be dreaming about covering them all.

Since parameters can contain EL as values as well, it wouldn't be crazy hard really to supply the encoding as a method expression. It's basically a byte[] -> String function.

In this case though I think encoding is a general enough moving part to warrant its own method in the interface. It can easily be defaulted to e.g. base64 and it can be overridden without exposing the implementation by use of a CDI decorator (or should be after we solve a bug or problem that currently prevents decorating).

Kind regards,
Arjan Tijms


On Thursday, July 20, 2017, Will Hopkins <will.hopkins@...> wrote:


On 07/20/2017 12:38 PM, Guillermo González de Agüero wrote:


Similarly, parameters like the salt and iteration count can be defaulted. That way you can have 3 levels:

1. Specify only the class name; you get defaults for all parameters and it Just Works
2. Specify the parameters locally to match a specific DB or requirement
3. (via EL) fetch the parameter values externally

The most important rule should always be that the developer is in full control, or can be in full control. External overrides should be possible, but never be required. That is -the- big mistake that Java EE made in the past.
I agree, but I think we're only talking about what the mechanism for override is, and what the trade-off between simplicity and the override mechanism is. In practice, I don't think parameters are going to be very helpful to most developers. They can be used to tweak some simple things, but the simple things won't typically be necessary and the more complex things can't be handled by parameters.
 
Could you please provide an example of such a setting, please? Just to better understand. Otherwise, we could just wait for your new proposal to see.

Basically, it's the encoding of the hashed password. Parameters like salt, iterations, hash key size, etc. are all pretty standard. They can be dialed up or dialed down to make the hash stronger or weaker, and I think "stronger vs. weaker" is the level at which most people think about them. I doubt many developers are concerned about specifying precisely a certain number of iterations for some reason, they just want iterations count to be high enough to be secure, without imposing excessive overhead or resource consumption, and security most often wins out vs. resource consumption these days. Most will be happy if they can turn up the volume with a single knob, they don't need bass and treble and balance knobs. Even better: if the default volume is about right, and if the volume automatically goes up when you're driving at higher speeds.

In contrast, the format of the encoded string is not standard in any way that I'm aware of. There are probably LDAP vendors that do things in a common way, but for any given database user store, either the format has already been decided, because there are existing user accounts, or the developer won't care as long as the default format is reasonable (assuming the DB schema allows enough space for the chosen encoding format.

I can't think of any good way to standardize parameters to describe how the hashed password is encoded for storage, and that's the hard part, the part that you really have to adapt to. It's not a big deal if you have to use 4000 iterations instead of 2000, but it's a big deal if you can't parse the encoded password. And since the encoding is completely arbitrary and non-standard, that's the real problem, and that's what will likely force people to do their own implementation of HashAlgorithm. That can't be specified as Properties.

We could probably come up with an interface for encoding/decoding the hashed value, or for describing the encoded value as a string and passing it as a property. But that's a lot to spec out, and we just don't have time for it. It's complicated by the fact that decoding a hash potentially yields all the parameters that were used to generate the hash, so there'd need to be a generalized interface for returning those in a standard way. Plus, in some databases, the encodings used will vary, as legacy hashes are replaced with stronger hashes/different encodings when people change their password.

It's hard to argue against supplying Properties. It's not difficult to implement, and it might be useful. But I'm trying to keep the interface as simple as possible -- in part to reduce the number of additional TCK tests that need to be written -- and I suspect the Properties will rarely be useful. Some people will want to use them, but for many the defaults will be good enough, and many of those with specific requirements will already be forced to write an implementation in order to deal with encoding issues.

Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Re: Expert Group meeting this week, or next?

Will Hopkins
 

Thanks, Arjan.

On 07/21/2017 04:07 PM, Arjan Tijms wrote:
Hi,

Seemed to work okay, got this:

Invitation from: Will Hopkins 
Subject: JSR-375 Expert Group Meeting
Time: Jul 24, 2017 2:00 PM Eastern Time (US and Canada) 



Which became:

8:00pm to 10:00pm in my calendar.

Kind regards,
Arjan Tijms


On Fri, Jul 21, 2017 at 8:33 PM, Will Hopkins <will.hopkins@...> wrote:
Monday it is, 1400 EST / 2000 CET.

I'll send out the invite. If someone could reply to confirm that they got the invite and that the time zone translated as expected, that would be great.

Thanks,

Will

On 07/19/2017 01:58 PM, Rudy De Busscher wrote:
OK for me too

On 19 July 2017 at 19:50, Arjan Tijms <arjan.tijms@...> wrote:
Fine for me too

On Wed, Jul 19, 2017 at 6:17 PM, Werner Keil <werner.keil@...> wrote:
Sounds fine for me on any day.



-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Re: Expert Group meeting this week, or next?

Arjan Tijms
 

Hi,

Seemed to work okay, got this:

Invitation from: Will Hopkins 
Subject: JSR-375 Expert Group Meeting
Time: Jul 24, 2017 2:00 PM Eastern Time (US and Canada) 



Which became:

8:00pm to 10:00pm in my calendar.

Kind regards,
Arjan Tijms


On Fri, Jul 21, 2017 at 8:33 PM, Will Hopkins <will.hopkins@...> wrote:
Monday it is, 1400 EST / 2000 CET.

I'll send out the invite. If someone could reply to confirm that they got the invite and that the time zone translated as expected, that would be great.

Thanks,

Will

On 07/19/2017 01:58 PM, Rudy De Busscher wrote:
OK for me too

On 19 July 2017 at 19:50, Arjan Tijms <arjan.tijms@...> wrote:
Fine for me too

On Wed, Jul 19, 2017 at 6:17 PM, Werner Keil <werner.keil@...> wrote:
Sounds fine for me on any day.



-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803



Re: Expert Group meeting this week, or next?

Will Hopkins
 

Monday it is, 1400 EST / 2000 CET.

I'll send out the invite. If someone could reply to confirm that they got the invite and that the time zone translated as expected, that would be great.

Thanks,

Will

On 07/19/2017 01:58 PM, Rudy De Busscher wrote:
OK for me too

On 19 July 2017 at 19:50, Arjan Tijms <arjan.tijms@...> wrote:
Fine for me too

On Wed, Jul 19, 2017 at 6:17 PM, Werner Keil <werner.keil@...> wrote:
Sounds fine for me on any day.



-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


JSR-375 Expert Group Meeting

Will Hopkins
 

Meeting Invite
Will Hopkins has invited you to
JSR-375 Expert Group Meeting
Date:Mon, Jul 24, 2017
Time:2:00 PM - 4:00 PM EDT
Location:Zoom -- see below for details
Organizer:Will Hopkins
Attendees:javaee-security-spec@javaee.groups.io; Will Hopkins
Description:

*~*~*~*~*~*~*~*~*~*

Let's meet to discusus the PFD draft, RI implementation state, and any remaining work required.

Oracle Zoom Conference Details
-----------------------------------------
Invitation from: Will Hopkins
Subject: JSR-375 Expert Group Meeting
Time: Jul 24, 2017 2:00 PM Eastern Time (US and Canada)
URL to join the Oracle Zoom Conference: https://oracle.zoom.us/j/924299498?pwd=bgIgFXSvb3s

The URL above provides one click access to the Zoom conference at the scheduled time from a PC, Mac, iOS or Android device.

Alternative ways to connect:
Go to https://oracle.zoom.us and click the "Join Meeting"
Meeting ID Number: 924 299 498
Meeting Password: 076440


Audio Information - Join by phone:

    +1 408 638 0968 or +1 646 558 8656 US Toll
    Meeting ID: 924 299 498
    International numbers available: https://oracle.zoom.us/zoomconference?m=b2SnII4LWkg4bXuDI7B-XdeeHXXiEbag 

New to Zoom?
-----------------
In preparation, please download the Zoom "Desktop Client" ahead of the meeting. Visit https://oracle.zoom.us for more information.


Re: Packaging bundle vs jar

Werner Keil
 

Then please have a look at the RI of JSR 363 just to give you one example:
https://github.com/unitsofmeasurement/unit-ri/blob/master/pom.xml

The resulting JAR can be found on MavenCentral: https://search.maven.org/#search%7Cga%7C1%7Ctec.units
OSGi info. A few additional details come from the maven-jar-plugin, everything else from Apache Felix maven-bundle-plugin.

HTH,
Werner


Re: Github Java EE organization memberschip

Will Hopkins
 

I'm not sure if something went wrong, or if they just changed the requirements, or if signing the OCA was already a requirement but it just wasn't clearly expressed. I did point out internally that some EG members who haven't signed the OCA have already contributed code, and was told that it wouldn't be a problem, but that future contributions require the OCA.

Note that the OCA is an Oracle agreement, for contributing to Oracle open source projects, whereas the JSPA agreement is a JCP agreement, and they apparently cover different things. Contributing actual code to an Oracle project isn't precisely the same as contributing ideas to a specification owned by the JCP, I guess.

Anyway, if this will be a problem I can look into it further, and find out what other options there are, if any. But the path of least resistance, and the quickest solution, will be to sign the OCA if you are able to.

Thanks,

Will


On 07/21/2017 10:30 AM, Rudy De Busscher wrote:
Will,

I signed the JSPA (JAVA SPECIFICATION PARTICIPATION AGREEMENT) in 01/2015 in order to be able to join the EG.

In june 2016, my employer signed the ECA in order that I can stay a Full JCP member.

At that time they assured me that I didn't need to do anything additional paperwork.

So what went wrong that apparently I wasn't allowed to contribute any code?

best regards
Rudy


On 21 July 2017 at 15:17, Will Hopkins <will.hopkins@...> wrote:
Yes, but, as noted in my mail announcing the move was complete, you'll need to sign the Oracle contributor agreement. I'm not sure what's up with that, and why simply being a member of the EG isn't sufficient, but that's what I'm being told is necessary.

https://javaee.github.io/CONTRIBUTING
http://www.oracle.com/technetwork/community/oca-486395.html

If signing the OCA is a problem for some reason, let me know, and I'll see if there are any other options. Given that you're on the EG and you've already made contributions, this seems silly.

Will



On July 21, 2017 5:08:24 AM EDT, Rudy De Busscher <rdebusscher@...> wrote:
Hi Will,

Can you also add me to the Java EE Organization and the "Java EE Security Team" just like all the other active EG members and contributors?

Thanks

Rudy


--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Re: Github Java EE organization memberschip

Rudy De Busscher
 

Will,

I signed the JSPA (JAVA SPECIFICATION PARTICIPATION AGREEMENT) in 01/2015 in order to be able to join the EG.

In june 2016, my employer signed the ECA in order that I can stay a Full JCP member.

At that time they assured me that I didn't need to do anything additional paperwork.

So what went wrong that apparently I wasn't allowed to contribute any code?

best regards
Rudy


On 21 July 2017 at 15:17, Will Hopkins <will.hopkins@...> wrote:
Yes, but, as noted in my mail announcing the move was complete, you'll need to sign the Oracle contributor agreement. I'm not sure what's up with that, and why simply being a member of the EG isn't sufficient, but that's what I'm being told is necessary.

https://javaee.github.io/CONTRIBUTING
http://www.oracle.com/technetwork/community/oca-486395.html

If signing the OCA is a problem for some reason, let me know, and I'll see if there are any other options. Given that you're on the EG and you've already made contributions, this seems silly.

Will



On July 21, 2017 5:08:24 AM EDT, Rudy De Busscher <rdebusscher@...> wrote:
Hi Will,

Can you also add me to the Java EE Organization and the "Java EE Security Team" just like all the other active EG members and contributors?

Thanks

Rudy


--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Re: Github Java EE organization memberschip

David Delabassee
 

That's correct! A signed OCA covers any and all Oracle sponsored open source projects. So you can only sign it once. ;-)

The reason we're asking which project a contributor is signing it for is just for initial routing reason, i.e. to forward the new contributor to a project owner.

--David


On Fri, Jul 21, 2017 at 4:03 PM, Arjan Tijms <arjan.tijms@...> wrote:
Hi,

I asked a similar question back then, but was told that "glassfish" would essentially cover all of Oracle's open source work, but I additionally entered "mojarra" too then, just to be totally sure.

Kind regards,
Arjan Tijms


On Fri, Jul 21, 2017 at 3:58 PM, Will Hopkins <will.hopkins@...> wrote:
The short answer is I don't actually know what you're supposed to put there, but if it's open-ended, "Java EE" would seem to cover all your contributions. Hopefully Dave can comment.

On July 21, 2017 9:52:23 AM EDT, "Guillermo González de Agüero" <z06.guillermo@...> wrote:
I signed for Soteria and I'm only listed for it. But David Delabasee explictly told me it applies to every project.

Cc'ing him here so he can clarify.


Regards,

Guillermo González de Agüero


El vie., 21 de julio de 2017 15:49, Werner Keil <werner.keil@...> escribió:
So 
>Project Name*:
is not a required field, or what did you write there?

Thanks,
Werner


--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803




Re: REPO MIGRATION COMPLETE

Arjan Tijms
 

Hi,

Thanks for taking the time to write this down and push the migration Will, great work!

I'll check out everything fresh here. Thx!

Kind regards,
Arjan Tijms




On Fri, Jul 21, 2017 at 5:13 AM, Will Hopkins <will.hopkins@...> wrote:
The repo migration is complete. Please take the time to read this email completely, as it explains how access to the repos works now, and what you'll need to know/do in order to contribute going forward.
  • The following repos are now hosted by the Java EE organization:
security-spec  (github.com/javaee/security-spec)
security-api  (github.com/javaee/security-spec)
security-soteria  (github.com/javaee/security-spec)
    • The security-api and security-soteria repos were transferred within github, so existing forks are still "connected", and existing clones should be redirected appropriately on push/pull. All commits, branches, tags, issues, etc., are intact. That said, it's probably a good idea to save any work in progress, delete existing forks/clones, and start fresh.
    • The security-spec repo was not transferred, instead it was cloned into an existing repo, with the same name, that already existed under the Java EE org. We lost the pull request history, but nothing else, AFAICT. All branches, commits, contributor information, etc., was carried over. You will need to recreate any existing forks or clones, or reconfigure them to point at the new repo. Access to the old security-spec repo has been disabled. I plan to delete it after the new repo has been "live" for a reasonable amount of time.
  • Access will work a little differently now:
    • For all three repos, members of the "Java EE Security Team" have write access to the repo. That means you can create branches, push to the repo, and create/update issues.
    • For the security-spec and security-api repos, the "master" branch is protected, so that only an organization or repo owner can push to it. I'm considering protecting the master branch of soteria such that pushing to master requires an approved review by someone with write access.
    • If you're not a member of the team, you can still submit a pull request or create an issue, but you won't be able to push changes or update issues. (And the pull request won't be accepted if you haven't signed the OCA, see below.)
    • Members of the team currently are myself, Arjan, Ivar, Alex Kosowski, and Ed Bratt. I have sent Guillermo an invitation to join the Java EE organization; assuming he accepts, he'll be added to the team as well.
  • If you intend to contribute, you MUST sign the OCA, and you SHOULD join the Java EE organization (for easier access):
    • All contributors must sign the Oracle Contributor Agreement (OCA), as explained here (http://www.oracle.com/technetwork/community/oca-486395.html). I was surprised to find that some EG members and "official" contributors (per the JCP site) aren't listed as having signed, including Werner, Rudy, and Ashley Richardson, apparently the OCA is distinct from what the JCP requires.
    • If you have signed the OCA and are a member of the Java EE organization, I'll add you to the "Java EE Security Team".
    • If you are not a member of the Java EE organization, and you'd like to be, and you've signed the OCA, let me know -- I'll send you an invite.
    • Note that that, when joining the Java EE organization, you are strongly encouraged, but not (yet) required, to:
      • Enable 2FA
      • Make your real name publicly visible
      • Update your avatar
Thanks for paying attention this long. If you have questions or have trouble getting access to the repos, let me know.

Regards,

Will

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803



Re: Github Java EE organization memberschip

Arjan Tijms
 

Hi,

I asked a similar question back then, but was told that "glassfish" would essentially cover all of Oracle's open source work, but I additionally entered "mojarra" too then, just to be totally sure.

Kind regards,
Arjan Tijms


On Fri, Jul 21, 2017 at 3:58 PM, Will Hopkins <will.hopkins@...> wrote:
The short answer is I don't actually know what you're supposed to put there, but if it's open-ended, "Java EE" would seem to cover all your contributions. Hopefully Dave can comment.

On July 21, 2017 9:52:23 AM EDT, "Guillermo González de Agüero" <z06.guillermo@...> wrote:
I signed for Soteria and I'm only listed for it. But David Delabasee explictly told me it applies to every project.

Cc'ing him here so he can clarify.


Regards,

Guillermo González de Agüero


El vie., 21 de julio de 2017 15:49, Werner Keil <werner.keil@...> escribió:
So 
>Project Name*:
is not a required field, or what did you write there?

Thanks,
Werner


--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803



Re: Github Java EE organization memberschip

Will Hopkins
 

Did you forget to Cc: Dave? I'd loop him in but I don't have his email on my phone.


On July 21, 2017 9:52:23 AM EDT, "Guillermo González de Agüero" <z06.guillermo@...> wrote:
I signed for Soteria and I'm only listed for it. But David Delabasee explictly told me it applies to every project.

Cc'ing him here so he can clarify.


Regards,

Guillermo González de Agüero


El vie., 21 de julio de 2017 15:49, Werner Keil <werner.keil@...> escribió:
So 
>Project Name*:
is not a required field, or what did you write there?

Thanks,
Werner


--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Re: Github Java EE organization memberschip

Will Hopkins
 

The short answer is I don't actually know what you're supposed to put there, but if it's open-ended, "Java EE" would seem to cover all your contributions. Hopefully Dave can comment.


On July 21, 2017 9:52:23 AM EDT, "Guillermo González de Agüero" <z06.guillermo@...> wrote:
I signed for Soteria and I'm only listed for it. But David Delabasee explictly told me it applies to every project.

Cc'ing him here so he can clarify.


Regards,

Guillermo González de Agüero


El vie., 21 de julio de 2017 15:49, Werner Keil <werner.keil@...> escribió:
So 
>Project Name*:
is not a required field, or what did you write there?

Thanks,
Werner


--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Re: Github Java EE organization memberschip

Guillermo González de Agüero
 

I signed for Soteria and I'm only listed for it. But David Delabasee explictly told me it applies to every project.

Cc'ing him here so he can clarify.


Regards,

Guillermo González de Agüero


El vie., 21 de julio de 2017 15:49, Werner Keil <werner.keil@...> escribió:
So 
>Project Name*:
is not a required field, or what did you write there?

Thanks,
Werner


Re: Github Java EE organization memberschip

Werner Keil
 

So 
>Project Name*:
is not a required field, or what did you write there?

Thanks,
Werner


Re: Github Java EE organization memberschip

Guillermo González de Agüero
 

Not sure it is related, but when I signed the OCA for Soteria I was told that was enough to contribute to any Oracle Open Source project


Regards,

Guillermo González de Agüero

El vie., 21 de julio de 2017 15:24, Werner Keil <werner.keil@...> escribió:
It's weird that the JSPA is not enough, but I even signed some confirmation about the upcoming EC F2F, so it should not be a problem.

What about the "project", does that mean, just like the infamous "Exhibit B" one has to sign an OCA for every single project (e.g. OpenJDK vs. Glassfish or even JSR 375/Soteria) ?

What would be the correct project name here, Glassfish or JSR 375?

Thanks,
Werner


Re: Github Java EE organization memberschip

Werner Keil
 

It's weird that the JSPA is not enough, but I even signed some confirmation about the upcoming EC F2F, so it should not be a problem.

What about the "project", does that mean, just like the infamous "Exhibit B" one has to sign an OCA for every single project (e.g. OpenJDK vs. Glassfish or even JSR 375/Soteria) ?

What would be the correct project name here, Glassfish or JSR 375?

Thanks,
Werner


Re: REPO MIGRATION COMPLETE

Will Hopkins
 

Right, thanks for catching that.


On July 21, 2017 5:00:58 AM EDT, Rudy De Busscher <rdebusscher@...> wrote:
For correctness, these are the URLs

security-spec  (github.com/javaee/security-spec)
security-api  (github.com/javaee/security-api)
security-soteria  (github.com/javaee/security-soteria)
Best regards
Rudy

    On 21 July 2017 at 05:13, Will Hopkins <will.hopkins@...> wrote:
    The repo migration is complete. Please take the time to read this email completely, as it explains how access to the repos works now, and what you'll need to know/do in order to contribute going forward.
    • The following repos are now hosted by the Java EE organization:
    security-spec  (github.com/javaee/security-spec)
    security-api  (github.com/javaee/security-spec)
    security-soteria  (github.com/javaee/security-spec)
      • The security-api and security-soteria repos were transferred within github, so existing forks are still "connected", and existing clones should be redirected appropriately on push/pull. All commits, branches, tags, issues, etc., are intact. That said, it's probably a good idea to save any work in progress, delete existing forks/clones, and start fresh.
      • The security-spec repo was not transferred, instead it was cloned into an existing repo, with the same name, that already existed under the Java EE org. We lost the pull request history, but nothing else, AFAICT. All branches, commits, contributor information, etc., was carried over. You will need to recreate any existing forks or clones, or reconfigure them to point at the new repo. Access to the old security-spec repo has been disabled. I plan to delete it after the new repo has been "live" for a reasonable amount of time.
    • Access will work a little differently now:
      • For all three repos, members of the "Java EE Security Team" have write access to the repo. That means you can create branches, push to the repo, and create/update issues.
      • For the security-spec and security-api repos, the "master" branch is protected, so that only an organization or repo owner can push to it. I'm considering protecting the master branch of soteria such that pushing to master requires an approved review by someone with write access.
      • If you're not a member of the team, you can still submit a pull request or create an issue, but you won't be able to push changes or update issues. (And the pull request won't be accepted if you haven't signed the OCA, see below.)
      • Members of the team currently are myself, Arjan, Ivar, Alex Kosowski, and Ed Bratt. I have sent Guillermo an invitation to join the Java EE organization; assuming he accepts, he'll be added to the team as well.
    • If you intend to contribute, you MUST sign the OCA, and you SHOULD join the Java EE organization (for easier access):
      • All contributors must sign the Oracle Contributor Agreement (OCA), as explained here (http://www.oracle.com/technetwork/community/oca-486395.html). I was surprised to find that some EG members and "official" contributors (per the JCP site) aren't listed as having signed, including Werner, Rudy, and Ashley Richardson, apparently the OCA is distinct from what the JCP requires.
      • If you have signed the OCA and are a member of the Java EE organization, I'll add you to the "Java EE Security Team".
      • If you are not a member of the Java EE organization, and you'd like to be, and you've signed the OCA, let me know -- I'll send you an invite.
      • Note that that, when joining the Java EE organization, you are strongly encouraged, but not (yet) required, to:
        • Enable 2FA
        • Make your real name publicly visible
        • Update your avatar
    Thanks for paying attention this long. If you have questions or have trouble getting access to the repos, let me know.

    Regards,

    Will

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    



    --
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803

    241 - 260 of 736