Version and Security

[forax at univ-mlv.fr]

Paul, 
you suggest to have two properties one for the version and of for the security fixes, 
i just said that i think that it easier if the two information are consolidated into one that is used as artifact name and module version. 

Rémi 

----- Mail original -----

> De: "Paul Benedict" <pbenedict at apache.org>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: verona-dev at openjdk.java.net
> Envoyé: Mardi 12 Janvier 2016 17:52:45
> Objet: Re: Version and Security

> Remi, one more addition from me. If the intent is really to flag which
> version has security fixes, you can use a qualifier for that. For example,
> Spring releases with the .SEC qualifier. The numbering is just an iteration;
> but no need to specify how many security iterations there has been in the
> version.

> Cheers,
> Paul

> On Tue, Jan 12, 2016 at 7:12 AM, Paul Benedict < pbenedict at apache.org >
> wrote:

> > Remi, thanks for the reply. I am not sure what you said is very important
> > for
> > ops. You can call the filename installer anything you want and document the
> > patches however. That's what ops are looking for in deciding when/how to
> > upgrade. So that doesn't mean the official versioning of the product has to
> > encode security iterations. I refer back to Martin's email regarding how
> > confusing the last digit is. I don't believe this is the way to go.
> 
> > On Jan 12, 2016 6:16 AM, "Remi Forax" < forax at univ-mlv.fr > wrote:
> 

> > > Hi Paul,
> > 
> 
> > > while using dates to indicate the last security patch is interesting,
> > 
> 
> > > you want the version of the produced artifact to reflect the security
> > > patch
> > > level to ease the work of the ops.
> > 
> 

> > > Rémi
> > 
> 

> > > ----- Mail original -----
> > 
> 
> > > > De: "Paul Benedict" < pbenedict at apache.org >
> > 
> 
> > > > À: verona-dev at openjdk.java.net
> > 
> 
> > > > Envoyé: Lundi 11 Janvier 2016 21:47:55
> > 
> 
> > > > Objet: Version and Security
> > 
> 
> > > >
> > 
> 
> > > > I'd like to offer a suggestion. I am late to the game with this idea,
> > > > but
> > > > I
> > 
> 
> > > > think it's worth mentioning. Right now I think the proposed encoding is
> > > > too
> > 
> 
> > > > complex and would like an alternative.
> > 
> 
> > > >
> > 
> 
> > > > I don't think the JDK version string should include any special
> > > > encoding
> > 
> 
> > > > for security. I believe product versioning and security patch
> > > > versioning
> > 
> 
> > > > should be made clear by 2 different system properties. There should be
> > > > an
> > 
> 
> > > > additional "security patch level" property that corresponds to the
> > > > version
> > 
> 
> > > > (or date) of either OpenJDK and/or Oracle for whatever their statuses
> > > > are.
> > 
> 
> > > >
> > 
> 
> > > > Example strings:
> > 
> 
> > > > java.version=9.0.1
> > 
> 
> > > > openjdk.java.security.level=2016-01-02
> > 
> 
> > > > oracle.java.security.level=2016-01-11
> > 
> 
> > > >
> > 
> 
> > > > How to interpret this example:
> > 
> 
> > > > Java 9.0.1 has all security patches from OpenJDK since 2016-01-02 and,
> > 
> 
> > > > because my example is using an Oracle JDK, it includes their own
> > 
> 
> > > > proprietary security patches up to 2016-01-11.
> > 
> 
> > > >
> > 
> 
> > > > Cheers,
> > 
> 
> > > > Paul
> > 
> 
> > > >
> > 
>