Re: API renaming

[Short, Todd]

They also correspond directly to EVP_MAC and EVP_KDF types. Would the types 
change as well?
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet."

> On Jul 23, 2020, at 11:56 AM, Matt Caswell  wrote:
> 
> 
> 
> On 23/07/2020 16:52, Richard Levitte wrote:
>> On Thu, 23 Jul 2020 12:18:10 +0200,
>> Dr Paul Dale wrote:
>>> There has been a suggestion to rename EVP_RAND to OSSL_RAND.  This seems 
>>> reasonable.  Would it
>>> also make sense to rename the other new APIs similarly.
>>> More specifically, EVP_MAC and EVP_KDF to OSSL_MAC and OSSL_KDF 
>>> respectively?
>> 
>> This is a good question...
>> 
>> Historically speaking, even though EVP_MAC and EVP_KDF are indeed new
>> APIs, they have a previous history of EVP APIs, through EVP_PKEY.  The
>> impact of relocating them outside of the EVP "family" may be small,
>> but still, history gives me pause.
>> 
>> RAND doesn't carry the same sort of history, which makes it much
>> easier for me to think "just do it and get it over with"...
> 
> I have the same pause - so  I'm thinking just RAND for now.
> 
> Matt
> 



signature.asc
Description: Message signed with OpenPGP

Re: Revisiting tradition: branches and tags

[Short, Todd]

As someone who is currently playing around with QUIC branches based on the tags 
and branch names, I *always* screw things up while typing. I wouldn't mind if 
the  key were banned from tags and branch names.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet."

> On Apr 13, 2020, at 1:09 PM, Richard Levitte  wrote:
> 
> On Mon, 13 Apr 2020 10:48:35 +0200,
> Matt Caswell wrote:
>> On 11/04/2020 10:53, Dr. Matthias St. Pierre wrote:
>>> I love the new naming scheme, in particular the fact that it's 
>>> all-lowercase and does not
>>> mix dashes and underscores anymore. I don't recall how often I cursed about 
>>> the current
>>> scheme which is so typer unfriendly.
>>> 
>>> I'd like to see *all* stable branch names and release tags converted to 
>>> new-style uniformly
>>> (keeping the old names for compatibility), so we have an overall consistent 
>>> scheme and people
>>> don't need to switch back and forth between naming conventions in the 
>>> future when doing
>>> historical investigations. The old names could be deprecated for later 
>>> removal.
>> 
>> Yes - this aspect was my main hesitation about the proposed new format,
>> i.e. the fact that we have a set of existing tags/branch names.
>> Constantly changing between the new format and the old format as we look
>> at older branches/tags could be painful. Just creating new tags for all
>> the existing ones would be one way forward.
> 
> New tags is perfectly possible to do.
> 
>> Typing OpenSSL_1_1_1-stable and getting all the right upper/lower case
>> characters in the right place and making sure to use _ vs - as
>> appropriate is a challenge for my fingers which I constantly fail.
> 
> I constantly fail the *current* names.
> 
>> Is it possible to set up alias names for the historical branches?
> 
> It's possible yes.  The hard part is 1.1.1.  There *is* something
> called 'git symbolic-ref', but they can only be added in repos we have
> physical access to, so while can add those on our git server, and they
> will work, we cannot add them in github.
> 
> Ref git help symbolic-ref
> 
> Cheers,
> Richard ( still thinks it's worth making the change with 3.0 )
> 
>> 
>> Matt
>> 
>> 
>>> 
>>> Matthias
>>> 
>>> 
>>> 
 -Original Message-
 From: openssl-project  On Behalf Of 
 Richard Levitte
 Sent: Friday, April 10, 2020 8:28 PM
 To: openssl-project@openssl.org
 Subject: Revisiting tradition: branches and tags
 
 Once upon a time, there was CVS (*).
 
 The story could stop there, but since CVS was what was available,
 OpenSSL was versioned with CVS.
 
 Among limitations that came with CVS was the allowed syntax in tag and
 branch names; letters, digits, dashes and underscores.  At the time,
 eveyone that wanted to encode a version number in a tag had to convert
 periods to some other character.  We chose underscores, ending up with
 tags like this:
 
OpenSSL_0_9_7-beta2
OpenSSL_0_9_7a
 
 Furthermore, the culture that we have with git, where branches are
 being pulled between repositories...  where you can actually have a
 multitude of repositories and pull data between them, was very hard if
 not practically impossible with CVS.  So, we occasionally had feature
 branches for longer term work.  To distinguish our so called stable
 branches, we had branch names with '-stable' added at the end:
 
OpenSSL_0_9_7-stable
 
 We *could* have had something shorter, like 'OpenSSL_0_9_7xx', but
 I guess that was too easy to mix up with our letter releases.
 
 With git, however, there's no technical reason why we must maintain
 what was originally a technical limitation.  I therefore propose that
 we start using tags like this starting with OpenSSL 3.0:
 
openssl-3.0.0-alpha1
openssl-3.0.0-beta2
openssl-3.0.0
openssl-3.0.1
openssl-3.1.0
 
 This is a little more than just avoiding to change the periods with
 underscores.  However, if you look at the tar files we've released for
 a long time, that's the naming format they use, and I can see benefits
 in having the tags for a release match the tar file of the same
 release:
 
openssl-0.9.7a.tar.gz
openssl-0.9.7a.tar.gz.asc
openssl-0.9.7a.tar.gz.md5
 
 Future tar files would be numbered with the new version scheme, of
 course:
 
openssl-3.0.0-alpha1.tar.gz
openssl-3.0.0-beta2.tar.gz
openssl-3.0.0.tar.gz
openssl-3.0.1.tar.gz
openssl-3.1.0.tar.gz
 
 So what about release branches?  We could actually follow a very
 similar new pattern, just replace the last digit with, say, an 'x', to
 signify that this branch will contain a series of patch releases:
 
openssl-3.0.x
 
 In this branch, one would expect to see the tags 'openssl-3.0.0',

Re: 1.1.1f

[Short, Todd]

This type of API-braking change should be reserved for something like 3.0, not 
a patch release.

Despite it being a "incorrect", it is expected behavior.

--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet."

> On Mar 26, 2020, at 11:03 AM, Dr. Matthias St. Pierre 
>  wrote:
> 
> I agree, go ahead. 
>  
> Please also consider reverting the change for the 3.0 alpha release as well, 
> see Daniel Stenbergs comment
> https://github.com/openssl/openssl/issues/11378#issuecomment-603730581 
> 
>  
> Matthias
>  
>  
> From: openssl-project  On Behalf Of 
> Dmitry Belyavsky
> Sent: Thursday, March 26, 2020 3:48 PM
> To: Matt Caswell 
> Cc: openssl-project@openssl.org
> Subject: Re: 1.1.1f
>  
>  
> On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell  > wrote:
> The EOF issue (https://github.com/openssl/openssl/issues/11378 
> )
>  has
> resulted in us reverting the original EOF change in the 1.1.1 branch
> (https://github.com/openssl/openssl/pull/11400 
> ).
> 
> Given that this seems to have broken quite a bit of stuff, I propose
> that we do a 1.1.1f soon (possibly next Tuesday - 31st March).
> 
> Thoughts?
>  
> I strongly support this idea.
>  
> -- 
> SY, Dmitry Belyavsky



smime.p7s
Description: S/MIME cryptographic signature

Upcoming releases?

[Short, Todd]

Hi openssl-project:

Given the typical release cadence and the imminent demise of 1.1.0, will there 
be another set bug fix releases (i.e. a final 1.1.0 release with friends)?

Thanks,

--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, threeif by the Internet."



smime.p7s
Description: S/MIME cryptographic signature

Re: punycode licensing

[Short, Todd]

This is the second time, that I'm aware of, that the wording of the CLA has 
prevented a PR from being accepted.

While this won't help the first case I'm aware of, perhaps there needs to be an 
exception/special-case in the CLA for code in RFCs, or other similar 
publications, where the author is basically saying "you can use this". The 
motive of the author may very well be done at the point of RFC publication, and 
has no interest in personally submitting the code to every open source project 
that may want it. As far as the authors are concerned, putting it into the RFC 
is sufficient.

--
-Todd Short
// Sent from my iPhone
// "One if by land, two if by sea, three if by the Internet."


On Jun 24, 2019, at 5:42 AM, Salz, Rich 
mailto:rs...@akamai.com>> wrote:


  *   Unfortunately, the issue isn't the compatibility of the license - they do 
indeed look relatively compatible to me - and the discussion on this thread has 
so far been about that.
  *   However the contributor license agreement requires that the copyright 
owner grants such permission - it is the fundamental basis of contributor 
agreements.

Yes, compatibility is important. CLA’s are required only for new code 
contributed to the project, not for code incorporated from elsewhere.  So if 
it’s compatible, CLA’s are not required.

At least, that was the position of the project and its former counsel during 
the first two years of relicensing.  Perhaps the OMC should raise this issue 
with current counsel if they disagree, but from the public statements on this 
list, it seems all but one agree.

As an aside, I’ve contacted the author and am having a productive exchange.  
Dimitry has seen the emails.