Re: Freeze?

2020-09-26 Thread Salz, Rich
As a sponsor of this release, we are concerned about further slippages in the schedule. I understand open source and “scratch your itch” and all that, but the project made a commitment and several companies have contributed money and/or engineering time. Some of those groups are making plans

Re: Beta1 PR deadline

2020-08-27 Thread Salz, Rich
>Please can anyone with PRs that they wish to have included in OpenSSL 3.0 beta1 ensure that they are merged to master by 8th September. And how are non-committers supposed to do that

Re: Backports to 1.1.1 and what is allowed

2020-06-22 Thread Salz, Rich
* I suggest everyone takes a read through

The hold on PR 12089

2020-06-10 Thread Salz, Rich
What is the timetable for resolving https://github.com/openssl/openssl/pull/12089 ? The Beta is planned for a July 16 release. There is a massive RAND/DRBG PR (https://github.com/openssl/openssl/pull/11682, the provider-friendly random) that is in the pipeline, and 12089 and 11682 will

Re: Detecting Bad OpenSSL Usage

2020-05-31 Thread Salz, Rich
It would be really interesting to run this over the apps. Maybe reach out to the author for help with that? From: Dmitry Belyavsky Date: Sunday, May 31, 2020 at 5:44 AM To: "openssl-project@openssl.org" Subject: Detecting Bad OpenSSL Usage Hello, Here is a nice article about a tool desired

Re: Reducing the security bits for MD5 and SHA1 in TLS

2020-05-27 Thread Salz, Rich
If you do this, you should add a FAQ (in addition to NEWS) explaining it.

error conversion macro's

2020-05-15 Thread Salz, Rich
Perhaps the next Alpha release can do the error macro conversion? Add script to convert XXXerr() to XXXerror, https://github.com/openssl/openssl/pull/9441 In particular, https://github.com/openssl/openssl/pull/9441#issuecomment-522171044 It might need updating if any new “error facility”

Re: Alpha2

2020-05-13 Thread Salz, Rich
>releases - we would simply do them every 3 weeks or so. I'd like to hear opinions on that proposal too. I am in favor of this, but you HAVE to keep the cadence regular: no slipping.

Re: Stale PR stats @May01

2020-05-01 Thread Salz, Rich
This is great transparency info. Failed CI's are a problem since it's often the fault of timeouts, or sometimes master is broken. Any thoughts on how to handle that? >So, ignoring deferred issues too you could summarise this as: Stale PRs waiting for us to do something: 27 (last

Re: CI build timeouts

2020-04-29 Thread Salz, Rich
* Disabling memory leak checking doesn’t sound like a great idea.. On that one platform, no?

Re: Cherry-pick proposal

2020-04-29 Thread Salz, Rich
I suspect that the primary motivation for this proposal is that PR’s against master often become stale because nobody on the project looks at them. And then submitters are told to rebase, fix conflicts, etc. It gets disheartening. If that is the motivation, then perhaps the project should

CI build timeouts

2020-03-30 Thread Salz, Rich
It’s time to disable that build, isn’t it? It’s timing out *AFTER AN HOUR* From: Tomáš Mráz Reply-To: openssl/openssl Date: Monday, March 30, 2020 at 9:51 AM To: openssl/openssl Cc: Subscribed Subject: Re: [openssl/openssl] [crypto/ec] blind coordinates in ec_wNAF_mul for robustness

Re: Deprecations

2020-03-05 Thread Salz, Rich
>Moreover, the deprecated commands print something to the effect of: "The >command dsa is deprecated. Use ‘pkey’ instead." when executed. I hope it only does that If (isatty(0) && isatty(1) && isatty(2)) { BIO_printf(bio_errerr, “%s: This command

Re: OpenSSL Logo (was: New GitHub Project Landing Page)

2020-02-27 Thread Salz, Rich
For what it’s worth, during the Website redesign I asked if anyone could provide a scalable logo so that our website worked on mobile, tablets, etc. Tony Arceri sent me a pure-CSS solution that worked and looked similar.

Re: Deprecations

2020-02-21 Thread Salz, Rich
>A small note about the 'no-deprecated' configuration option: this is an > option to simulate the far future when the deprecated stuff has been removed > from the public eye. Deprecated openssl commands should not build with such a > configuration. How can that work? If the deprecated

Re: Deprecation

2020-02-14 Thread Salz, Rich
* I think we should delay the deprecation of engine stuff to 4.0. Personally I don't have sense of stability of provider API. I share this concern. This is the first release of the provider infrastructure, and while it will be known to work for FIPS modules, it’s hubris to think OpenSSL

QUIC support

2020-02-06 Thread Salz, Rich
A month ago Tim said[2] that PR 8797[1] requires on OMC decision on “whether or not QUIC in this manner of approach should be added into OpenSSL at this time.” To save you a click, this PR adds API’s to OpenSSL so that Google’s open source QUIC implementation can be built on top of OpenSSL.

Re: Travis in solid red mode again

2020-02-03 Thread Salz, Rich
> Could we add a CI check for PRs that confirms that the target branch is green in travis? Looking at https://docs.travis-ci.com/user/notifications/#conditional-notifications and https://config.travis-ci.com/ref/notifications/email it seems like it should be fairly easy configure

Re: Travis in solid red mode again

2020-02-03 Thread Salz, Rich
>Oh, actually, maybe I'm wrong. Is it just Appveyor that posts failures and not Travis? Yes. You need to config travis to mail failures, as I pointed out in my earlier message.

Re: fips mode and key management

2020-01-21 Thread Salz, Rich
>distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would be more fitting than FIPS_MODE? Or perhaps OPENSSL_BUILDING_FIPS, since a couple of PR's already have and use OPENSSL_BUILDING_OPENSSL ... There's no reason to use OSSL for internal macros.

Re: crypt(3)

2020-01-20 Thread Salz, Rich
* I meant “what default makes the most sense for the passwd command line application?” * It was crypt which is deprecated. Should it be BSD’s MD5? One of the SHA2 based algorithms? Or should it produce an error if no algorithm is selected? If you change the default, then the program

FW: Coverity Scan: Analysis completed for OpenSSL-1.0.2

2020-01-03 Thread Salz, Rich
Someone should turn off 1.0.2 :) On 1/2/20, 11:48 PM, "scan-ad...@coverity.com" wrote: Your request for analysis of OpenSSL-1.0.2 has been completed successfully. The results are available at

OTC membership?

2019-12-29 Thread Salz, Rich
The list of committers is at https://www.openssl.org/community/committers.html The list of OMC members is at https://www.openssl.org/community/omc.html Will there be a list of OTC members also in the community tab soon? Or a mark in the committers table?

Re: Check NULL pointers or not...

2019-12-02 Thread Salz, Rich
* In a production environment, it is almost never appropriate to simply crash in an uncontrolled manner (i.e. dereferencing a NULL pointer). Applications that want this can check parameters themselves before calling the function. Saying “C arguments don’t hold” is only because it goes

Re: Check NULL pointers or not...

2019-12-02 Thread Salz, Rich
if (!ossl_assert(ptr != NULL)) { ERR_raise(ERR_LIB_WHATEVER, ERR_R_PASSED_NULL_PARAMETER); return 0; } If the project decides to do this, I would like a configure option to ONLY turn on ossl_assert so that previous behavior can be restored without debug

Re: Malloc failures check

2019-11-21 Thread Salz, Rich
* It would be possible to implement a malloc failure feature in the test suite that systematically runs a test many times, failing successive malloc calls. It’s there; look crypto/mem.c, shouldfail() and FAILTEST. More detail, from off-list discusson: i=0 while : ; do

Re: Malloc failures check

2019-11-21 Thread Salz, Rich
* It would be possible to implement a malloc failure feature in the test suite that systematically runs a test many times, failing successive malloc calls. It’s there; look crypto/mem.c, shouldfail() and FAILTEST.

Re: #10388

2019-11-14 Thread Salz, Rich
>I’m more concerned about adding these to 3.0. It means we’ll have to support >the new API for a long time and it is one which we are currently trying to >move away from. Will you? Have you already decided that 3.0 is an LTS release? Otherwise, you have the LTS burden and when the rest of

Re: Confirmed bug labels

2019-10-29 Thread Salz, Rich
What about "proposed bug" "proposed feature" etc. And a single "accepted" label?

FW: Interview participation request

2019-10-21 Thread Salz, Rich
Folks, I did a Skype call with James. You might want to let him talk to you so that it’s more than just my view :) It was fun. He’s done a lot of number-crunching of OpenSSL through the years, including things like complexity (depth of nesting) and such. Maybe you can do a group-chat during

UK or US spelling in manages?

2019-10-03 Thread Salz, Rich
OpenSSL is in the final stages of a *massive* cleanup of the manpages. Many of them are nit-level things, bringing them into conformance with common style, as expressed at http://man7.org/linux/man-pages/man7/man-pages.7.html There is on notable difference: openssl uses a mix of UK and US

Re: RAND, FIPS and providers

2019-09-24 Thread Salz, Rich
FWIW, I agree with Matt's points.

Re: Thread sanitiser problems

2019-07-30 Thread Salz, Rich
Do you need to hold the lock across dependant items? For example, why can't the DRBG code unlock before fetching the AES-CTR code?

Re: Do we really want to have the legacy provider as opt-in only?

2019-07-17 Thread Salz, Rich
> If DSA is almost never used, why enable it by default? I am amused/bemused that, after years of saying we do not know what people are doing with OpenSSL, it now is now becoming common practice to blithely assert "this is not used" when it fits the personal viewpoint of some folks.

Re: Do we really want to have the legacy provider as opt-in only?

2019-07-15 Thread Salz, Rich
>>DSA > > What is the cryptographic weakness of DSA that you are avoiding? It's a good question. I don't recall the specific reason why that was added to the list. Perhaps others can comment. The only weakness I know about is that if you re-use the nonce, the

Re: Do we really want to have the legacy provider as opt-in only?

2019-07-15 Thread Salz, Rich
>DSA What is the cryptographic weakness of DSA that you are avoiding?

Re: punycode licensing

2019-07-10 Thread Salz, Rich
I will take the hint and stop commenting on this thread.

Re: punycode licensing

2019-07-10 Thread Salz, Rich
Thank you for the reply. >The license under which the OpenSSL software is provided does not require >"permission" to be sought for use of the software. See

Re: punycode licensing

2019-07-10 Thread Salz, Rich
Thank you for the update. This brings to mind a few additional questions: 1. Does other code which is copyright/licensed under the Apache 2 license also require CLAs? 2. Does other code which is in the public domain also require CLAs? 3. Does OpenSSL expect that anyone using OpenSSL

Re: punycode licensing

2019-06-24 Thread Salz, Rich
* 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

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Salz, Rich
>So basically, what you're actually saying is that we should add additional errors up the call stack... so if some function called OPENSSL_zalloc(), it should be perfectly OK to raise a ERR_R_MALLOC_FAILURE, but functions above should *add* things like

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Salz, Rich
>The proper way to handle this, in my experience, is *DO NOT REUSE ERROR > CODES.* Each error code appears in exactly one place, and we could eventually > build up documentation explaining what they mean, the causes, and how to > address this. This means, we don't use ERR_R_MALLOC when

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Salz, Rich
I think exposing the function internals is a mistake for a couple of reasons: it encourages familiarity with, and dependence on, OpenSSL library internals, and it goes against the spirit of layering, and there is no guarantee that the function code does not change as internal code gets moved

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Salz, Rich
>The kernel actually already does this in recent versions, if configured to do it. "The" kernel. Which one is that? Which operating system? Modern Linux is fine. Is that all we care about? No issues were raised when the RSA keylength was increased, or MD5 was replaced with SHA1.

Re: OSSL_PARAMs

2019-06-05 Thread Salz, Rich
* Is this workable or should something more significantly different be used before things freeze with the 3.0 release? Well, since you asked: https://github.com/openssl/openssl/pull/8377

Re: OSSL_PARAMs

2019-06-04 Thread Salz, Rich
>Part of the idea was that this would be a means of communication between application and provider, just like controls are with libcrypto sub-systems. I can probably find the email thread (or maybe it was a GitHub comment on my proposal for params), where you said, quite

Re: proposed change to committers policy

2019-05-24 Thread Salz, Rich
Nicely worded. It doesn’t go as far as I’d like, but it’s a step.

Re: No two reviewers from same company

2019-05-24 Thread Salz, Rich
> In that example the potential conflict of interest comes from the > individual's employment with the third party organisation, not because they are fellows. Do you disagree with my contention that the OMC represents the project, and not the fellows? Regardless of where the conflict

Re: No two reviewers from same company

2019-05-23 Thread Salz, Rich
> In private email, and https://github.com/openssl/openssl/pull/8886#issuecomment-494624313 the implication is that this was a policy. AFAIK this is not the case. Is the comment wrong, either factually or because it is implementing something that isn't an official policy? >

Re: No two reviewers from same company

2019-05-23 Thread Salz, Rich
> I understand that OpenSSL is changing things so that, by mechanism (and maybe by > policy although it’s not published yet), two members of the same company cannot > approve the same PR. That’s great. (I never approved Akamai requests unless it > was trivial back when I was

No two reviewers from same company

2019-05-23 Thread Salz, Rich
I understand that OpenSSL is changing things so that, by mechanism (and maybe by policy although it’s not published yet), two members of the same company cannot approve the same PR. That’s great. (I never approved Akamai requests unless it was trivial back when I was on the OMC.) Should this

Re: Update

2019-05-22 Thread Salz, Rich
>> I'd be opposed to this last option without IANA/IETF being on board. By doing so >we are effectively no longer compliant with IETF TLS since we're using certain >codepoints and version numbers to mean things that IETF/IANA have no visibility >of, i.e. we would be

Re: Update

2019-05-21 Thread Salz, Rich
> I'd be opposed to this last option without IANA/IETF being on board. By > doing so we are effectively no longer compliant with IETF TLS since we're using certain codepoints and version numbers to mean things that IETF/IANA have no visibility of, i.e. we would be doing

Re: Update

2019-05-20 Thread Salz, Rich
>I don't see it that way. As I understand it this is a completely different protocol to standard TLS. That's an interesting point, but ... they use the SSL "name." > It is not intended to interoperate with it in any way. Is that true? I didn't look closely at the protocol changes, but

Re: Update

2019-05-20 Thread Salz, Rich
* The current requirement for inclusion is “national

Re: SP 800-90C 10.1.2

2019-04-11 Thread Salz, Rich
No love from Akamai for this: it seems to be done for completionist reasons and it seems risky. From: "paul.d...@oracle.com" Date: Tuesday, April 9, 2019 at 8:07 PM To: "fips-spons...@openssl.org" Cc: "openssl-project@openssl.org" Subject: SP 800-90C 10.1.2 Do any of the FIPS sponsors or

Re: [openssl-project] OpenSSL 3.0 and FIPS Update

2019-02-15 Thread Salz, Rich
>We won't be offering the service to add new platforms onto our own > certificate, but you should be able perform your own validation for your own platforms based on ours (I forget the correct FIPS term for this...perhaps someone more FIPSy than I am can chip in).

Re: [openssl-project] Fractional seconds, etc.

2018-08-14 Thread Salz, Rich
I mean keep the *previous* behavior. On 8/14/18, 9:25 AM, "Salz, Rich" wrote: >This seems to have been done in both the 1.0.2 and 1.1.0 after the release. Do you want to revert it in both branches, but keep it in 1.1.1? Or only revert it in 1.0.2?

Re: [openssl-project] Fractional seconds, etc.

2018-08-14 Thread Salz, Rich
>This seems to have been done in both the 1.0.2 and 1.1.0 after the release. Do you want to revert it in both branches, but keep it in 1.1.1? Or only revert it in 1.0.2? Keep the existing behavior for 1.0.2, 1.1.0 and 1.1.1. Sadly. And fix in a future release (I would re-open the

[openssl-project] Fractional seconds, etc.

2018-08-14 Thread Salz, Rich
I think we should revert https://github.com/openssl/openssl/pull/2668 The stricter RFC compliance turns out to impact many certs embedded in devices. Some estimates had thousands to millions. It affects interop with IAIK and Bouncy Castle. I looked at the code, and tried to figure out how to

Re: [openssl-project] Releases tomorrow

2018-08-13 Thread Salz, Rich
>- "Updates for RFC8446 (the final TLSv1.3 version)" (PR 6741) needs to be merged. I have the required approval, just giving Rich some time to see if he has any further comments. Thanks, I'm good. >- If we're going to make any changes for issue 6904 (broken pipe for clients

[openssl-project] FW: Certificate fractional time processing in upcoming openssl releases

2018-08-11 Thread Salz, Rich
So it seems counter to the spirit of the RFC to prevent openSSL from being able to interoperate with certs issued by IAIK or whatever noncompliant systems. Thanks, David From: "Salz, Rich" mailto:rs...@akamai.com>> Date: Friday, August 10, 2018 at 12:24 PM To: "Barry Fus

[openssl-project] TLS 1.3 and the release

2018-08-11 Thread Salz, Rich
You probably know by now that TLS 1.3 was just released as RFC 8446;

Re: [openssl-project] Removal of NULL checks

2018-08-09 Thread Salz, Rich
>Whether one's for them, or against them, removing a check from a function that would formerly return an error and making it crash is a substantial API change. I don't disagree. ___ openssl-project mailing list

Re: [openssl-project] Reuse of PSKs between TLSv1.2 and TLSv1.3

2018-08-09 Thread Salz, Rich
>"We should remove the TLSv1.2 to TLSv1.3 PSK compatibility mechanism as discussed in issue 6490. If TLSv1.2 PSKs are configured (and not TLSv1.3 PSKs) then we should disable TLSv1.3." This seems reasonable to me, albeit a bit wordy since you could delete the first sentence. :)

Re: [openssl-project] Removal of NULL checks

2018-08-09 Thread Salz, Rich
>it's NULL. Now imagine that this stack was some kind of deny list. If >entry producer didn't pay attention to error when creating stack and >putting things into it, consumer would be led to belief that there is >nothing to deny and let through the requests that are supposed to be

Re: [openssl-project] master is broken?

2018-07-24 Thread Salz, Rich
sudo cpan Carp::Always I did this. Same results for config and the PERLOPT setting. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] master is broken?

2018-07-24 Thread Salz, Rich
On 7/24/18, 1:42 PM, "Richard Levitte" wrote: Would you mind installing it? The package is called libcarp-always-perl on Debian and derivates, and if my RPM search fu isn't entirely off, the corresponding RPM package is perl-Carp-Always Or install with cpan... Okay.

Re: [openssl-project] master is broken?

2018-07-24 Thread Salz, Rich
; env | grep PERL ; PERL5OPT=-MCarp::Always ./config Operating system: x86_64-whatever-linux2 Can't locate Carp/Always.pm in @INC (you may need to install the Carp::Always module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5

[openssl-project] master is broken?

2018-07-24 Thread Salz, Rich
; g status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean ; g pull Current branch master is up to date. ; ; ./config Operating system: x86_64-whatever-linux2 Configuring OpenSSL version 1.1.1-pre9-dev (0x10101009L) for linux-x86_64

[openssl-project] Taking a break

2018-07-20 Thread Salz, Rich
I am going to take a break from most of OpenSSL governance for the rest of the month. As I have been mostly the person handling all those other things, and as I am usually very very quick with email, I thought the project should know. I’m not going anywhere, it’s really just like the first

[openssl-project] Finishing up this release

2018-07-12 Thread Salz, Rich
We’re close to finishing the 1.1.1 release. As we’ve said before, this is our next LTS release which means it will be supported for five years. There are a few things we still need to do and we’re encouraging the community to help. These include: Address all the “1.1.1” open issues, found at

Re: [openssl-project] Milestones and the 1.1.1 release

2018-07-02 Thread Salz, Rich
Thanks for finishing this off. https://github.com/openssl/openssl/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.1.1 Are 6512 and 6396 the same, and closed because we made things more secure? Is 6342 a python bug, they'll need to upgrade? Is 6228 a foolscap issue? I think we can close

[openssl-project] FW: [openssl-commits] Build failed in Jenkins: master_noec #574

2018-06-26 Thread Salz, Rich
FYI On 6/26/18, 2:45 PM, "Barry Fussell (bfussell)" wrote: The evp_test is failing intermittently because there is an attempt to malloc zero bytes when running the new test that came in with this commit.

[openssl-project] GitHub labels

2018-06-20 Thread Salz, Rich
I think it’s a good idea that we periodically review the labels we’re using. Please look at https://github.com/openssl/openssl/labels and maybe suggest changes. ___ openssl-project mailing list openssl-project@openssl.org

Re: [openssl-project] Beta release today

2018-06-19 Thread Salz, Rich
>It would still be good if someone can freeze the repo though please: ssh openssl-...@git.openssl.org freeze openssl matt I will do this tonight, eastern time. ___ openssl-project mailing list openssl-project@openssl.org

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-11 Thread Salz, Rich
>Except that, because of the way PKCS12_gen_mac() works, this isn't true. If the input pass phrase looks like a UTF-8 encoded string (because there are valid characters in other encodings that will like like UTF-8 byte sequences), it will be used as if -passutf8 was given

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-11 Thread Salz, Rich
>I have zero idea what the doc says, because I haven't seen the docs yet. Did I miss the PR? No. It's posted here on the mailing list for discussion and reposted here: +=item B<-passutf8>, B<-pass8bit> + +These flags indicate the character set encoding on the password value. +By

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-11 Thread Salz, Rich
>However, what's going to happen is that PKCS12_gen_mac() will generate this for a BMPString: Which is what we do now, right? And the docs for this *new flag* explain that the behavior could change in the future. To be "pass8bit" means "pass 8bit bytes through to lower layer" But if

Re: [openssl-project] [openssl-omc] stepping down from OMC

2018-06-11 Thread Salz, Rich
* I'm leaving the project. https://www.youtube.com/watch?v=YtsZoIe3Czk You have a great deal to be proud of, and OpenSSL is much better for the time you spent here. We will miss you. I will miss you. ___ openssl-project mailing list

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-11 Thread Salz, Rich
> If B<-pass8bit> is given, the password is taken to be encoded in the current > locale, but is still used directly. > A future release might automatically convert the password to valid UTF-8 > encoding if this flag is given. I would propose that "-pass8bit" means that

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-07 Thread Salz, Rich
password to valid UTF-8 encoding if this flag is given. On 6/7/18, 3:42 PM, "Salz, Rich" wrote: >So even rejecting correctly encoded utf-8? I think you forgot that this is not what I suggested. One flag indicates it's utf-8 encoded, don't touch it. The other f

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-07 Thread Salz, Rich
>So even rejecting correctly encoded utf-8? I think you forgot that this is not what I suggested. One flag indicates it's utf-8 encoded, don't touch it. The other flag indicates it might have high-bit chars, don't touch it. ___

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-07 Thread Salz, Rich
>My main concern is that currently, openssl pkcs12 may create broken pkcs12 > files (because it misinterprets the pass phrase when constructing a > BMPString), and doesn't notify the user at all (doesn't even check). For those who haven't reada the PR and all its comments, I propose that

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-07 Thread Salz, Rich
>We don't have to answer the question "how high" now. I'm fully prepared to have the use of iconv limited to platforms where we know it's available That then means that the pkcs12 program is not compatible in behavior across platforms. This would be a first, for us.

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-07 Thread Salz, Rich
>Taking off on a bit of a tangent, how much justification did we go through when adding pthreads as a dependency. It's an optional, but enabled by default, dependency which is different. We had a lot of discussion within what was then openssl-team.

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-07 Thread Salz, Rich
I see you already started the votes. No time for discussion? I think OpenSSL should be a "fundamental" system library. Perhaps the apps are different, but it should not require new libraries but could use them if available -- either at run-time or via config/build. I think iconv in

Re: [openssl-project] Is Mac a supported platform?

2018-06-02 Thread Salz, Rich
https://github.com/openssl/openssl/pull/6404 On 6/1/18, 5:33 PM, "Richard Levitte" wrote: In message <1bd96940-3b3b-4758-938a-01e576306...@akamai.com> on Fri, 1 Jun 2018 21:26:12 +0000, "Salz, Rich" said: rsalz> >Regarding the original qu

Re: [openssl-project] Is Mac a supported platform?

2018-06-01 Thread Salz, Rich
>Regarding the original question, it's "supported" insofar that we have osx among the Travis builds (at least usually... there have been times when the osx backlog has been so great that we've temporarly disabled it). So maybe I should just create a PR to update INSTALL with

Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

2018-06-01 Thread Salz, Rich
>I think that the gist of the difference of opinion is whether it's OK to use locale dependent functions such as mbstowcs in libcrypto or not. Thanks for the summary. I am against use locale-dependent functions in libcrypto. ___

Re: [openssl-project] Current votes FYI

2018-05-23 Thread Salz, Rich
ote simply did not pass. Tim. On Thu, 24 May 2018, 12:59 am Salz, Rich, <rs...@akamai.com<mailto:rs...@akamai.com>> wrote: Another update VOTE: Remove the second paragraph ("Binary compatibility...improve security") from the relea

Re: [openssl-project] build/test before merging

2018-05-23 Thread Salz, Rich
>Unfortunately, I didn't have time to follow my vision yet. Also, it would > have been easier for me to do it in Python than in Perl. +1 for python! :) ___ openssl-project mailing list openssl-project@openssl.org

[openssl-project] FW: [TLS] WGLC for draft-ietf-tls-tls13-vectors

2018-05-08 Thread Salz, Rich
Anyone want to take a look at wedging this into our test suite? On 5/8/18, 12:31 PM, "Sean Turner" wrote: All, This is the working group last call for the "Example Handshake Traces for TLS 1.3" draft available at

Re: [openssl-project] Beta release on Tuesday

2018-04-30 Thread Salz, Rich
>Nobody else has stepped forward. Are you still available for this? Sure. >I would normally start around 12.00 UTC, but could push it a bit later if it works better for you. So that's 7am, it would be best to delay an hour. ___

Re: [openssl-project] Freezing the repo

2018-04-30 Thread Salz, Rich
Done. On 4/30/18, 3:02 PM, "Matt Caswell" wrote: Please could someone freeze the repo for me for tomorrow's release: $ ssh openssl-...@git.openssl.org freeze openssl matt Thanks Matt ___

Re: [openssl-project] Beta release on Tuesday

2018-04-27 Thread Salz, Rich
>As normal we are planning a new beta release on Tuesday. This means that >we will be freezing the repo from Monday afternoon (UTC). I'm in US but available if nobody "closer" can do it. ___ openssl-project mailing list

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

2018-04-19 Thread Salz, Rich
I am not fond of Viktor's reply, which comes across as "pshaw silly ninny" or something like that. David has pointed out valid use-cases. I think most use-cases will "just work." We should document the known sharp edges. ___ openssl-project

Re: [openssl-project] Problems with waiting for specific person to merge

2018-04-19 Thread Salz, Rich
>Self assigning is a good habit... unless you have my tendencies, to *ahem* forget that you've self assigned something. There's a built-in filter that says "find my PR's" It's just on the left side of the search box. ___ openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-18 Thread Salz, Rich
>Would still like to know what's motivating Google's insistence on SNI... The TLS WG is probably the place to ask this. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-17 Thread Salz, Rich
So far, if there's no SNI then we shouldn't do TLS 1.3 (as a client). That seems easy to code. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project

  1   2   >