From kaduk at mit.edu Mon Jul 2 14:15:19 2018 From: kaduk at mit.edu (Benjamin Kaduk) Date: Mon, 2 Jul 2018 09:15:19 -0500 Subject: [openssl-project] thread-unsafety in SNI handling with SSL_SESSION Message-ID: <20180702141518.GE22125@kduck.kaduk.org> Hi folks, https://github.com/openssl/openssl/pull/4519 introduced some thread-unsafe behavior, and we had some discussion on that (closed) PR back in May, which led to the creation of https://github.com/openssl/openssl/pull/6378 . The latter one has languished for a while, partly because I was slow in making some needed fixups. But it may be worth revisiting now, if anyone has some time to spare. Thanks, Bne From matt at openssl.org Mon Jul 2 16:51:53 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 2 Jul 2018 17:51:53 +0100 Subject: [openssl-project] Milestones and the 1.1.1 release In-Reply-To: <16cd0d05-e301-9a68-f464-267175e0d21b@openssl.org> References: <6a460a10-face-5780-7c6f-885a7e0e3ecb@openssl.org> <98E3F9EB-D27D-4307-945F-A921E3FF3E29@akamai.com> <16cd0d05-e301-9a68-f464-267175e0d21b@openssl.org> Message-ID: <45f31899-94c1-69dd-a72e-4599044b1534@openssl.org> On 27/06/18 16:10, Matt Caswell wrote: > Well, no one has objected so far. I'm not around tomorrow and Friday to > action this but, unless anyone shouts between now and then, I'll start > doing this on Monday. All issues have been reviewed and their milestones updated accordingly. I also reviewed all issues that had no milestone assigned. That leaves us with 18 open issues against the 1.1.1 milestone: https://github.com/openssl/openssl/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.1.1 IMO, getting these closed (or otherwise moved out of the 1.1.1 milestone) should be our priority focus area in the coming weeks. Matt > > Matt > > > On 26/06/18 21:15, Matt Caswell wrote: >> >> >> On 26/06/18 20:43, Salz, Rich wrote: >>> That's interesting. Would we put a bugfix in 1.1.0, not put the fix in 1.1.1 until our first "a" release? >>> >>> Or are you saying that if it's in 1.1.0, then we don't have to fix it until after 1.1.1 comes out? That seems justifiable to me. >> >> The latter. >> >> I mean it doesn't *prevent* us from fixing something that's in both >> 1.1.0 and 1.1.1 - but our focus should be on fixing issues that are >> newly introduced in 1.1.1. >> >> Matt >> >>> >>> ?On 6/26/18, 3:32 PM, "Matt Caswell" wrote: >>> >>> >>> >>> On 26/06/18 18:18, Salz, Rich wrote: >>> > So are you saying look at the 73 open issues at https://github.com/openssl/openssl/milestone/9 and re-evaluate them? >>> >>> Exactly. My guess is that a significant proportion of them also apply to >>> 1.1.0 and therefore should not hold up the 1.1.1 release. At the moment >>> though it is impossible to tell which are the high priority issues we >>> should be focussing on. >>> >>> Matt >>> >>> >>> > >>> > >>> > >>> > On 6/26/18, 11:56 AM, "Matt Caswell" wrote: >>> > >>> > I'm thinking that we should maybe re-asses the current milestones in github. >>> > >>> > We currently use the following milestones: >>> > >>> > Assessed - Anything against this milestone isn't relevant to the 1.1.1 >>> > release (e.g. 1.0.2 specific issue) >>> > >>> > 1.1.1 - This is relevant to the 1.1.1 release but may not be specific to >>> > it (e.g. an issue that affects both 1.1.1 and 1.1.0) >>> > >>> > Post 1.1.1 - Feature request to be looked at once 1.1.1 is released >>> > >>> > >>> > I think we should re-asses everything currently against the 1.1.1 >>> > milestone so that anything which isn't specific to that release gets >>> > moved to the "Assessed" milestone. >>> > >>> > At the moment its difficult to see the "wood for the trees" between >>> > issues which are newly introduced and those that are long standing. In >>> > terms of getting the 1.1.1 release out the door we should focus on the >>> > former. >>> > >>> > Thoughts? >>> > >>> > Matt >>> > >>> > _______________________________________________ >>> > openssl-project mailing list >>> > openssl-project at openssl.org >>> > https://mta.openssl.org/mailman/listinfo/openssl-project >>> > >>> > >>> > _______________________________________________ >>> > openssl-project mailing list >>> > openssl-project at openssl.org >>> > https://mta.openssl.org/mailman/listinfo/openssl-project >>> > >>> _______________________________________________ >>> openssl-project mailing list >>> openssl-project at openssl.org >>> https://mta.openssl.org/mailman/listinfo/openssl-project >>> >>> _______________________________________________ >>> openssl-project mailing list >>> openssl-project at openssl.org >>> https://mta.openssl.org/mailman/listinfo/openssl-project >>> >> _______________________________________________ >> openssl-project mailing list >> openssl-project at openssl.org >> https://mta.openssl.org/mailman/listinfo/openssl-project >> From rsalz at akamai.com Mon Jul 2 17:36:42 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 2 Jul 2018 17:36:42 +0000 Subject: [openssl-project] Milestones and the 1.1.1 release In-Reply-To: <45f31899-94c1-69dd-a72e-4599044b1534@openssl.org> References: <6a460a10-face-5780-7c6f-885a7e0e3ecb@openssl.org> <98E3F9EB-D27D-4307-945F-A921E3FF3E29@akamai.com> <16cd0d05-e301-9a68-f464-267175e0d21b@openssl.org> <45f31899-94c1-69dd-a72e-4599044b1534@openssl.org> Message-ID: <9CF490FB-1D9E-49E2-99E2-75DCD50F4295@akamai.com> 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 6221 soon. I will make a PR for 5037. From matt at openssl.org Tue Jul 3 09:03:34 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 3 Jul 2018 10:03:34 +0100 Subject: [openssl-project] Milestones and the 1.1.1 release In-Reply-To: <9CF490FB-1D9E-49E2-99E2-75DCD50F4295@akamai.com> References: <6a460a10-face-5780-7c6f-885a7e0e3ecb@openssl.org> <98E3F9EB-D27D-4307-945F-A921E3FF3E29@akamai.com> <16cd0d05-e301-9a68-f464-267175e0d21b@openssl.org> <45f31899-94c1-69dd-a72e-4599044b1534@openssl.org> <9CF490FB-1D9E-49E2-99E2-75DCD50F4295@akamai.com> Message-ID: <5f485ce5-57ca-aa26-9283-f3fa1358d199@openssl.org> On 02/07/18 18:36, Salz, Rich wrote: > 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? They may be the same, or maybe not. Almost certainly this is the result of the SCA mitigations we've put in place. For 6512 @romen was going to do some testing and report back, so I've pinged him. For 6396 the answer may be to implement 6418 which should help quite a lot. There is some doubt though whether we can get that in quickly enough. Awaiting further input from @bbbrumley. In both cases I think we should keep them open for now. I wouldn't consider either as showstoppers though. > > Is 6342 a python bug, they'll need to upgrade? Maybe. Pinged @tiran for an update. > > Is 6228 a foolscap issue? > A comment in 6234 says that the foolscap issue was solved by setting SSL_MODE_AUTO_RETRY on by default, so I closed this issue. > I think we can close 6221 soon. Probably, yes. Matt From matt at openssl.org Thu Jul 5 10:30:39 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 5 Jul 2018 11:30:39 +0100 Subject: [openssl-project] Monthly Status Report (June) Message-ID: <5089e520-b6fb-51f9-0fe5-3238b747e59a@openssl.org> As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Implemented a feature enabling anti-replay to be switched off - Enabled SSL_OP_NO_TICKET support for TLSv1.3 - Added getters for raw private/public keys to improve X25519/X448/Ed25519/Ed448 support - Worked on numerous SM2 tidy ups - Fixed an issue with incorrect TLSv1.3 ticket nonces - Ported an old patch for binary ecc lambda projective co-ordinates by Billy Brumley to latest master. This work has now been taken over by Billy. - Attended some teleconference calls on the FIPS project - Fixed no-dsa - Fixed a problem with the EAP-FAST support - Fixed no-ec - Continued work started in May around auto-retry in shutdown - Continued work started in May around TLSv1.3 alert severity levels - Worked on and issued security advisory for CVE-2018-0732 - Implemented blinding for ECDSA and DSA - Fixed a problem in s_client which was not correctly reporting TLSv1.3 session data - Investigated and fixed an OSS-fuzz detected issue with the alpn_selected SSL_SESSION data - Fixed enable-ssl3 and enable-ssl3-method - Fixed no-ssl3-method in 1.0.2 - Performed the 1.1.1-pre8 release - Helped investigate test failures in the pyca external tests - Fixed and documented no-sm2 - Fixed a problem where session data was being changed after it is supposed to be immutable - Developed patches for various SM2 issues discovered by Coverity - Fixed a NULL ptr deref in tls_process_cke_dhe() - Fixed various issues relating to the client side cache in TLSv1.3 - Involved in discussions with David Benjamin around Universal PSKs Matt From matt at openssl.org Fri Jul 6 22:42:24 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 6 Jul 2018 23:42:24 +0100 Subject: [openssl-project] Forthcoming holidays In-Reply-To: References: Message-ID: Just a reminder that I am on holiday from Sunday with limited/no access to email. I will be back working from Friday. Matt On 27/06/18 09:56, Matt Caswell wrote: > FYI, I have a few days off coming up which will mean I am less > responsive than normal. I will have very limited/no access to email > during these periods: > > Thursday 28th - Friday 29th June > > and > > Sunday 8th - Thursday 12th July > > > Matt > From paul.dale at oracle.com Tue Jul 10 23:31:06 2018 From: paul.dale at oracle.com (Paul Dale) Date: Tue, 10 Jul 2018 16:31:06 -0700 (PDT) Subject: [openssl-project] ghmerge problem Message-ID: <4e6348f6-e6a2-4b6c-8410-d83b4c945042@default> I'm getting a problem during the rebuild stage where the option -Qunused-arguments isn't being recognised by gcc. I don't see this option in the latest gcc documentation or for the version I use (4.8.4). It looks like an option for clang. Is this a problem with the configuration or with my build set up? Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Wed Jul 11 06:21:52 2018 From: levitte at openssl.org (Richard Levitte) Date: Wed, 11 Jul 2018 08:21:52 +0200 (CEST) Subject: [openssl-project] ghmerge problem In-Reply-To: <4e6348f6-e6a2-4b6c-8410-d83b4c945042@default> References: <4e6348f6-e6a2-4b6c-8410-d83b4c945042@default> Message-ID: <20180711.082152.1331117441988423757.levitte@openssl.org> In message <4e6348f6-e6a2-4b6c-8410-d83b4c945042 at default> on Tue, 10 Jul 2018 16:31:06 -0700 (PDT), Paul Dale said: paul.dale> I?m getting a problem during the rebuild stage where the paul.dale> option ?Qunused-arguments isn?t being recognised by gcc. paul.dale> paul.dale> I don?t see this option in the latest gcc documentation or paul.dale> for the version I use (4.8.4). It looks like an option for paul.dale> clang. paul.dale> paul.dale> Is this a problem with the configuration or with my build set up? ghmerge uses 'opensslbuild' to rebuild. If you have your own, you'll have to take a closer look there. The 'opensslbuild' that comes with ghmerge only sets that option of $CC contains the string 'clang'... I haven't tested, though... -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From paul.dale at oracle.com Wed Jul 11 21:24:59 2018 From: paul.dale at oracle.com (Paul Dale) Date: Wed, 11 Jul 2018 14:24:59 -0700 (PDT) Subject: [openssl-project] ghmerge problem In-Reply-To: <20180711.082152.1331117441988423757.levitte@openssl.org> References: <4e6348f6-e6a2-4b6c-8410-d83b4c945042@default> <20180711.082152.1331117441988423757.levitte@openssl.org> Message-ID: <9a51464e-6088-4454-9f24-a6b3f0bded67@default> Richard, Thanks for the pointer. I've figured out the problem and have submitted a PR. It was three fold: * I didn't have clang-3.6 installed. * the opensslbuild script sets CC if it isn't already set but doesn't use or export it. It does add the option based on the local value. * the configure script used gcc since CC wasn't getting to it. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -----Original Message----- From: Richard Levitte [mailto:levitte at openssl.org] Sent: Wednesday, 11 July 2018 4:22 PM To: openssl-project at openssl.org Subject: Re: [openssl-project] ghmerge problem In message <4e6348f6-e6a2-4b6c-8410-d83b4c945042 at default> on Tue, 10 Jul 2018 16:31:06 -0700 (PDT), Paul Dale said: paul.dale> I?m getting a problem during the rebuild stage where the paul.dale> option ?Qunused-arguments isn?t being recognised by gcc. paul.dale> paul.dale> I don?t see this option in the latest gcc documentation or paul.dale> for the version I use (4.8.4). It looks like an option for paul.dale> clang. paul.dale> paul.dale> Is this a problem with the configuration or with my build set up? ghmerge uses 'opensslbuild' to rebuild. If you have your own, you'll have to take a closer look there. The 'opensslbuild' that comes with ghmerge only sets that option of $CC contains the string 'clang'... I haven't tested, though... -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ _______________________________________________ openssl-project mailing list openssl-project at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project From rsalz at akamai.com Thu Jul 12 17:54:43 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 12 Jul 2018 17:54:43 +0000 Subject: [openssl-project] Finishing up this release Message-ID: 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 https://github.com/openssl/openssl/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.1.1 Any input or advice is appreciated; particularly for issues reported by (or against) other projects. No open 1.1.1 PR?s that are more than two weeks old. If an issue or a PR affects other releases, then it can wait. You can see the PR?s at https://github.com/openssl/openssl/pulls, and adding feedback or code-review or other comments (particularly to the recent ones) will help. No open Coverity issues. You can find the public scan reports at https://scan.coverity.com/projects/openssl (you have to register first, we?ll approve anyone). A PR to address issues, or an email pointing out which are false positives can help. Clean builds in travis, Appveyor, and our run-checker script. We are doing well with this. We are planning on doing one last beta after the TLS 1.3 RFC is published. There is little anyone can do about that, except to wait. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Jul 18 09:18:37 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 18 Jul 2018 10:18:37 +0100 Subject: [openssl-project] Forthcoming holiday Message-ID: <4c3b6c85-ebe6-777f-1341-e1126372029f@openssl.org> I have some more holiday coming up :-) I'll be away next week: Tuesday 24th July - Friday 27th July. Matt From rsalz at akamai.com Fri Jul 20 12:08:05 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 20 Jul 2018 12:08:05 +0000 Subject: [openssl-project] Taking a break Message-ID: <1118EC1E-94A5-4BA9-BAB2-C92279EEB0FC@akamai.com> 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 sentence says. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Jul 20 14:33:41 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 20 Jul 2018 15:33:41 +0100 Subject: [openssl-project] Current 1.1.1 status compared to Release criteria Message-ID: I've done a review of the 1.1.1 release criteria against the current status. See below. TL;DR summary: Status is generally good. There are some outstanding issues and PRs that need input from various people. Specifically there are actions for: @levitte, @paulidale, @dot-asm, @mspncp, @t-j-h Criteria: All open github issues/PRs older than 2 weeks at the time of release to be assessed for relevance to 1.1.1. Any flagged with the 1.1.1 milestone to be closed Status: There are currently 7 open issues flagged against 1.1.1. Of these 1 has had a fix merged and we're awaiting confirmation that the fix has worked. 2 have fixes available in currently open PRs. The remaining 4 are: 6490: Reuse of PSKs between TLS 1.2 and TLS 1.3 is questionable This is the subject of current IETF TLS WG debate. One option is to simply disable TLS1.3 if 1.2 PSKs are in use. 5944: Policy issue: TLSv1.3 makes upgrade without program modification impossible I think this can be closed, but I'd like @levitte to confirm 3901: pthread_atfork for android API < 21 It's unclear to me what needs to be done here. 3254: flaws in OpenSSL-1.1.1-dev builds on Windows I'm not sure what the next step is. @levitte probably needs to take another look. There are 8 currently open PRs flagged against 1.1.1. 3 of these are new (within the last couple of days). The remaining 5 older ones are: 6694: Update sm2_crypt.c We're waiting on a CLA or confirmation of triviality. Also @paulidale had a comment, which has been responded to. Not sure if it was a satisfactory answer (@paulidale should probably check). 6623: Fix potential NULL pointer dereference in EVP "int_ctx_new" It's unclear what needs to happen next. 6596: crypto/o_fopen.c: alias fopen to fopen64 @t-j-h made a comment...awaiting a response from @dot-asm 6075: Increase number of MR tests for RSA prime generation Waiting on review comments from @mspncp 5035: Recreate OS390-Unix Awaiting input from @t-j-h. It's not clear to me if this issue justifies the 1.1.1 label? I think OS390 is an issue even in 1.1.0? Criteria: Clean builds in Travis and Appveyor for two days Status: Both Travis and Appveyor are currently clean. Criteria: run-checker.sh to be showing as clean 2 days before release Status: run-checker is currently clean. Criteria: No open Coverity issues (not flagged as "False Positive" or "Ignore") Status: There is one currently open Coverity issue not flagged as "false positive" or "ignore". This issue has been fixed, and should be cleared the next time coverity is updated. Criteria: TLSv1.3 RFC published (with at least one beta release after the publication) Status: The RFC number will be 8446. The RFC Editor has done the first pass editing, and those edits are being reviewed by ekr. See https://github.com/tlswg/tls13-rfc. From our perspective we are ready to apply the final RFC updates as soon as it is published (see PR 6741), so we should be able to do the final beta release shortly afterwards. Matt From rsalz at akamai.com Mon Jul 23 17:53:47 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 23 Jul 2018 17:53:47 +0000 Subject: [openssl-project] TLS 1.3 use stats Message-ID: <04A92939-D37D-4150-ABF9-9F369DA2FF3A@akamai.com> At the IETF last week, I showed the attached slide on TLS 1.3 adoption that we?ve seen. It is with an open beta, where a small percentage of our customers enabled TLS 1.3 The connections/day is a small fraction of our daily traffic. Both number of customers and connections are rounded off to a couple of percents of the totals. But this is still interesting, I think. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tls13.png Type: image/png Size: 340284 bytes Desc: tls13.png URL: From levitte at openssl.org Tue Jul 24 12:08:46 2018 From: levitte at openssl.org (Richard Levitte) Date: Tue, 24 Jul 2018 14:08:46 +0200 (CEST) Subject: [openssl-project] To distribute just the repo file, or the result of 'make dist'? Message-ID: <20180724.140846.1287409772932331226.levitte@openssl.org> This is a question that's been asked before, and that has popped up again in https://github.com/openssl/openssl/issues/6765 Our current mechanism for creating tarballs for a new OpenSSL release is to run 'make dist' in any given build tree... it's a bit clumsy, as it needs a wasted configuration if it's done in a newly checked out work tree, but is designed to work correctly from any build tree. The original intention (way back, I think we're even talking SSLeay time here, but at the very least pre-1.0.0 time) was to make a tarball that can be built directly with just a 'make' on any Unix box and without requiring perl. Since 1.1.0, though, the tarballs do require perl to generate certain files, such as include/openssl/opensslconf.h. That makes a pre-configured distribution less benefitial. Also, if anyone tries to run 'nmake' on Windows without configuring first, they get a nasty and quite confusing surprise... I think the same happens on VMS, although I haven't tested that. I can see two way to fix this: 1. Don't release pre-configured tarballs. This is a very simple thing to do, all we have to do is use 'make tar' to create tarballs instead of 'make dist'. We could remove the dist target entirely while we're at it. 2. Restore the no-perl benefit with a tarball distributed with 'make dist' (which is very simple due to 'make build_all_generated'). 3. Have the 'dist' config target generate a really dumbed down Makefile that contains the same well known targets as the usual build files, but makes sure to run some kind of fancy script (supposedly in perl) that runs a proper configuration for the platform at hand. (actually, the first item doesn't depend on the rest, but the answer will direct our focus) Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kurt at roeckx.be Tue Jul 24 12:28:40 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 24 Jul 2018 14:28:40 +0200 Subject: [openssl-project] To distribute just the repo file, or the result of 'make dist'? In-Reply-To: <20180724.140846.1287409772932331226.levitte@openssl.org> References: <20180724.140846.1287409772932331226.levitte@openssl.org> Message-ID: <20180724122839.GA2433@roeckx.be> On Tue, Jul 24, 2018 at 02:08:46PM +0200, Richard Levitte wrote: > > The original intention (way back, I think we're even talking SSLeay > time here, but at the very least pre-1.0.0 time) was to make a tarball > that can be built directly with just a 'make' on any Unix box and > without requiring perl. I don't see how that could work our current system. As far as I know, it's actually confired for a system, and it will not work properly on an other. It would just work on the same system as that we ran config on. > 1. Don't release pre-configured tarballs. This is a very simple > thing to do, all we have to do is use 'make tar' to create > tarballs instead of 'make dist'. We could remove the dist target > entirely while we're at it. This makes most sense to me. Kurt From kaduk at mit.edu Tue Jul 24 12:55:04 2018 From: kaduk at mit.edu (Benjamin Kaduk) Date: Tue, 24 Jul 2018 07:55:04 -0500 Subject: [openssl-project] To distribute just the repo file, or the result of 'make dist'? In-Reply-To: <20180724122839.GA2433@roeckx.be> References: <20180724.140846.1287409772932331226.levitte@openssl.org> <20180724122839.GA2433@roeckx.be> Message-ID: <20180724125503.GH92448@kduck.kaduk.org> On Tue, Jul 24, 2018 at 02:28:40PM +0200, Kurt Roeckx wrote: > On Tue, Jul 24, 2018 at 02:08:46PM +0200, Richard Levitte wrote: > > > > The original intention (way back, I think we're even talking SSLeay > > time here, but at the very least pre-1.0.0 time) was to make a tarball > > that can be built directly with just a 'make' on any Unix box and > > without requiring perl. > > I don't see how that could work our current system. As far as I > know, it's actually confired for a system, and it will not work > properly on an other. It would just work on the same system as > that we ran config on. > > > 1. Don't release pre-configured tarballs. This is a very simple > > thing to do, all we have to do is use 'make tar' to create > > tarballs instead of 'make dist'. We could remove the dist target > > entirely while we're at it. > > This makes most sense to me. To me as well. (As a side note, OpenAFS also has something called 'make dist' that is functionally different, but also has deep historical roots and is also something I'm trying to get rid of.) -Ben From levitte at openssl.org Tue Jul 24 13:50:55 2018 From: levitte at openssl.org (Richard Levitte) Date: Tue, 24 Jul 2018 15:50:55 +0200 (CEST) Subject: [openssl-project] To distribute just the repo file, or the result of 'make dist'? In-Reply-To: <20180724122839.GA2433@roeckx.be> References: <20180724.140846.1287409772932331226.levitte@openssl.org> <20180724122839.GA2433@roeckx.be> Message-ID: <20180724.155055.721916182736074624.levitte@openssl.org> In message <20180724122839.GA2433 at roeckx.be> on Tue, 24 Jul 2018 14:28:40 +0200, Kurt Roeckx said: kurt> On Tue, Jul 24, 2018 at 02:08:46PM +0200, Richard Levitte wrote: kurt> > kurt> > The original intention (way back, I think we're even talking SSLeay kurt> > time here, but at the very least pre-1.0.0 time) was to make a tarball kurt> > that can be built directly with just a 'make' on any Unix box and kurt> > without requiring perl. kurt> kurt> I don't see how that could work our current system. As far as I kurt> know, it's actually confired for a system, and it will not work kurt> properly on an other. It would just work on the same system as kurt> that we ran config on. Hmm? The dist target (Configurations/dist.conf) creates a *very* generic Makefile with no system specific files. It assumes LP32 and very generic C compiler command line. It doesn't support assembler modules, threads or shared libraries... that cuts away quite a lot of system dependencies. The only thing that's needed to make the resulting directory tree free of the need for perl is 'make build_all_generated'. kurt> > 1. Don't release pre-configured tarballs. This is a very simple kurt> > thing to do, all we have to do is use 'make tar' to create kurt> > tarballs instead of 'make dist'. We could remove the dist target kurt> > entirely while we're at it. kurt> kurt> This makes most sense to me. Yes, it does to me as well, especially considering we're encouraging everyone to configure anyway. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Tue Jul 24 16:49:24 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 24 Jul 2018 16:49:24 +0000 Subject: [openssl-project] master is broken? Message-ID: <21FE7178-6410-48F4-AD17-152454DE00B5@akamai.com> ; 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 Using os-specific seed configuration Failure! build file wasn't produced. Please read INSTALL and associated NOTES files. You may also have to look over your available compiler tool chain or change your configuration. Failure! build file wasn't produced. Please read INSTALL and associated NOTES files. You may also have to look over your available compiler tool chain or change your configuration. Failure! build file wasn't produced. Please read INSTALL and associated NOTES files. You may also have to look over your available compiler tool chain or change your configuration. Creating configdata.pm Creating Makefile ********************************************************************** *** *** *** If you want to report a building issue, please include the *** *** output from this command: *** *** *** *** perl configdata.pm --dump *** *** *** ********************************************************************** ; ; perl configdata.pm --dump Command line (with current working directory = .): /usr/bin/perl ./Configure linux-x86_64 Perl information: /usr/bin/perl 5.18.2 for x86_64-linux-gnu-thread-multi Enabled features: aria asm async autoalginit autoerrinit autoload-config bf blake2 camellia capieng cast chacha cmac cms comp ct deprecated des dgram dh dsa dso dtls dynamic-engine ec ec2m ecdh ecdsa engine err filenames gost hw(-.+)? idea makedepend md4 mdc2 multiblock nextprotoneg ocb ocsp pic poly1305 posix-io psk rc2 rc4 rdrand rfc3779 rmd160 scrypt seed shared siphash sm2 sm3 sm4 sock srp srtp sse2 ssl static-engine stdio tests threads tls ts ui-console whirlpool tls1 tls1-method tls1_1 tls1_1-method tls1_2 tls1_2-method tls1_3 dtls1 dtls1-method dtls1_2 dtls1_2-method Disabled features: afalgeng [too-old-kernel] asan [default] OPENSSL_NO_ASAN crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG crypto-mdebug-backtrace [default] OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE devcryptoeng [default] OPENSSL_NO_DEVCRYPTOENG ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 egd [default] OPENSSL_NO_EGD external-tests [default] OPENSSL_NO_EXTERNAL_TESTS fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER fuzz-afl [default] OPENSSL_NO_FUZZ_AFL heartbeats [default] OPENSSL_NO_HEARTBEATS md2 [default] OPENSSL_NO_MD2 (skip crypto/md2) msan [default] OPENSSL_NO_MSAN rc5 [default] OPENSSL_NO_RC5 (skip crypto/rc5) sctp [default] OPENSSL_NO_SCTP ssl-trace [default] OPENSSL_NO_SSL_TRACE tls13downgrade [default] OPENSSL_NO_TLS13DOWNGRADE ubsan [default] OPENSSL_NO_UBSAN unit-test [default] OPENSSL_NO_UNIT_TEST weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS zlib [default] zlib-dynamic [default] ssl3 [default] OPENSSL_NO_SSL3 ssl3-method [default] OPENSSL_NO_SSL3_METHOD Config target attributes: AR => "ar", ARFLAGS => "r", CC => "gcc", CFLAGS => "-Wall -O3", CXX => "g++", CXXFLAGS => "-Wall -O3", HASHBANGPERL => "/usr/bin/env perl", RANLIB => "ranlib", RC => "windres", aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s aesni-mb-x86_64.s", aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o", apps_aux_src => "", apps_init_src => "", apps_obj => "", bf_asm_src => "bf_enc.c", bf_obj => "bf_enc.o", bn_asm_src => "asm/x86_64-gcc.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s", bn_obj => "asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o", bn_ops => "SIXTY_FOUR_BIT_LONG", build_file => "Makefile", build_scheme => [ "unified", "unix" ], cast_asm_src => "c_enc.c", cast_obj => "c_enc.o", cflags => "-pthread -m64", chacha_asm_src => "chacha-x86_64.s", chacha_obj => "chacha-x86_64.o", cmll_asm_src => "cmll-x86_64.s cmll_misc.c", cmll_obj => "cmll-x86_64.o cmll_misc.o", cppflags => "", cpuid_asm_src => "x86_64cpuid.s", cpuid_obj => "x86_64cpuid.o", cxxflags => "-std=c++11 -pthread -m64", defines => [ ], des_asm_src => "des_enc.c fcrypt_b.c", des_obj => "des_enc.o fcrypt_b.o", disable => [ ], dso_extension => ".so", dso_scheme => "dlfcn", ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s x25519-x86_64.s", ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o", enable => [ "afalgeng" ], ex_libs => "-ldl -pthread", exe_extension => "", includes => [ ], keccak1600_asm_src => "keccak1600-x86_64.s", keccak1600_obj => "keccak1600-x86_64.o", lflags => "", lib_cflags => "", lib_cppflags => "-DOPENSSL_USE_NODELETE -DL_ENDIAN", lib_defines => [ ], md5_asm_src => "md5-x86_64.s", md5_obj => "md5-x86_64.o", modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s", modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o", module_cflags => "-fPIC", module_cxxflags => "", module_ldflags => "-Wl,-znodelete -shared -Wl,-Bsymbolic", multilib => "64", padlock_asm_src => "e_padlock-x86_64.s", padlock_obj => "e_padlock-x86_64.o", perlasm_scheme => "elf", poly1305_asm_src => "poly1305-x86_64.s", poly1305_obj => "poly1305-x86_64.o", rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s", rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o", rc5_asm_src => "rc5_enc.c", rc5_obj => "rc5_enc.o", rmd160_asm_src => "", rmd160_obj => "", sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s sha1-mb-x86_64.s sha256-mb-x86_64.s", sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o", shared_cflag => "-fPIC", shared_defflag => "-Wl,--version-script=", shared_defines => [ ], shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)", shared_extension_simple => ".so", shared_ldflag => "-Wl,-znodelete -shared -Wl,-Bsymbolic", shared_rcflag => "", shared_sonameflag => "-Wl,-soname=", shared_target => "linux-shared", thread_defines => [ ], thread_scheme => "pthreads", unistd => "", uplink_aux_src => "", uplink_obj => "", wp_asm_src => "wp-x86_64.s", wp_obj => "wp-x86_64.o", Recorded environment: AR = ARFLAGS = AS = ASFLAGS = BUILDFILE = CC = CFLAGS = CPP = CPPDEFINES = CPPFLAGS = CPPINCLUDES = CROSS_COMPILE = CXX = CXXFLAGS = HASHBANGPERL = LD = LDFLAGS = LDLIBS = MT = MTFLAGS = OPENSSL_LOCAL_CONFIG_DIR = PERL = RANLIB = RC = RCFLAGS = RM = WINDRES = __CNF_CFLAGS = __CNF_CPPDEFINES = __CNF_CPPFLAGS = __CNF_CPPINCLUDES = __CNF_CXXFLAGS = __CNF_LDFLAGS = __CNF_LDLIBS = Makevars: AR = ar ARFLAGS = r CC = gcc CFLAGS = -Wall -O3 CPPDEFINES = CPPFLAGS = CPPINCLUDES = CXX = g++ CXXFLAGS = -Wall -O3 HASHBANGPERL = /usr/bin/env perl LDFLAGS = LDLIBS = PERL = /usr/bin/perl RANLIB = ranlib RC = windres NOTE: These variables only represent the configuration view. The build file template may have processed these variables further, please have a look at the build file for more exact data: Makefile build file: Makefile build file templates: Configurations/common0.tmpl Configurations/unix-Makefile.tmpl Configurations/common.tmpl ; -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Tue Jul 24 17:33:06 2018 From: levitte at openssl.org (Richard Levitte) Date: Tue, 24 Jul 2018 19:33:06 +0200 (CEST) Subject: [openssl-project] master is broken? In-Reply-To: <21FE7178-6410-48F4-AD17-152454DE00B5@akamai.com> References: <21FE7178-6410-48F4-AD17-152454DE00B5@akamai.com> Message-ID: <20180724.193306.328060713509212733.levitte@openssl.org> I can't reproduce, but looking into using Carp::Always uncovered a couple of bugs, which I'm submitting a PR for. When that is merged, you should be able to do this, and get a stack trace every time the death handler is called: PERL5OPT=-MCarp::Always ./config BTW, would you be so kind and check the value of $PERL5OPT for me? That might be relevant... Cheers, Richard In message <21FE7178-6410-48F4-AD17-152454DE00B5 at akamai.com> on Tue, 24 Jul 2018 16:49:24 +0000, "Salz, Rich" said: rsalz> ; g status rsalz> On branch master rsalz> Your branch is up-to-date with 'origin/master'. rsalz> nothing to commit, working directory clean rsalz> ; g pull rsalz> Current branch master is up to date. rsalz> ; rsalz> rsalz> ; ./config rsalz> Operating system: x86_64-whatever-linux2 rsalz> Configuring OpenSSL version 1.1.1-pre9-dev (0x10101009L) for linux-x86_64 rsalz> Using os-specific seed configuration rsalz> rsalz> Failure! build file wasn't produced. rsalz> Please read INSTALL and associated NOTES files. You may also have to look over rsalz> your available compiler tool chain or change your configuration. rsalz> rsalz> rsalz> Failure! build file wasn't produced. rsalz> Please read INSTALL and associated NOTES files. You may also have to look over rsalz> your available compiler tool chain or change your configuration. rsalz> rsalz> rsalz> Failure! build file wasn't produced. rsalz> Please read INSTALL and associated NOTES files. You may also have to look over rsalz> your available compiler tool chain or change your configuration. rsalz> rsalz> Creating configdata.pm rsalz> Creating Makefile rsalz> rsalz> ********************************************************************** rsalz> *** *** rsalz> *** If you want to report a building issue, please include the *** rsalz> *** output from this command: *** rsalz> *** *** rsalz> *** perl configdata.pm --dump *** rsalz> *** *** rsalz> ********************************************************************** rsalz> ; rsalz> ; perl configdata.pm --dump rsalz> rsalz> Command line (with current working directory = .): rsalz> rsalz> /usr/bin/perl ./Configure linux-x86_64 rsalz> rsalz> Perl information: rsalz> rsalz> /usr/bin/perl rsalz> 5.18.2 for x86_64-linux-gnu-thread-multi rsalz> rsalz> Enabled features: rsalz> rsalz> aria rsalz> asm rsalz> async rsalz> autoalginit rsalz> autoerrinit rsalz> autoload-config rsalz> bf rsalz> blake2 rsalz> camellia rsalz> capieng rsalz> cast rsalz> chacha rsalz> cmac rsalz> cms rsalz> comp rsalz> ct rsalz> deprecated rsalz> des rsalz> dgram rsalz> dh rsalz> dsa rsalz> dso rsalz> dtls rsalz> dynamic-engine rsalz> ec rsalz> ec2m rsalz> ecdh rsalz> ecdsa rsalz> engine rsalz> err rsalz> filenames rsalz> gost rsalz> hw(-.+)? rsalz> idea rsalz> makedepend rsalz> md4 rsalz> mdc2 rsalz> multiblock rsalz> nextprotoneg rsalz> ocb rsalz> ocsp rsalz> pic rsalz> poly1305 rsalz> posix-io rsalz> psk rsalz> rc2 rsalz> rc4 rsalz> rdrand rsalz> rfc3779 rsalz> rmd160 rsalz> scrypt rsalz> seed rsalz> shared rsalz> siphash rsalz> sm2 rsalz> sm3 rsalz> sm4 rsalz> sock rsalz> srp rsalz> srtp rsalz> sse2 rsalz> ssl rsalz> static-engine rsalz> stdio rsalz> tests rsalz> threads rsalz> tls rsalz> ts rsalz> ui-console rsalz> whirlpool rsalz> tls1 rsalz> tls1-method rsalz> tls1_1 rsalz> tls1_1-method rsalz> tls1_2 rsalz> tls1_2-method rsalz> tls1_3 rsalz> dtls1 rsalz> dtls1-method rsalz> dtls1_2 rsalz> dtls1_2-method rsalz> rsalz> Disabled features: rsalz> rsalz> afalgeng [too-old-kernel] rsalz> asan [default] OPENSSL_NO_ASAN rsalz> crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG rsalz> crypto-mdebug-backtrace [default] OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE rsalz> devcryptoeng [default] OPENSSL_NO_DEVCRYPTOENG rsalz> ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 rsalz> egd [default] OPENSSL_NO_EGD rsalz> external-tests [default] OPENSSL_NO_EXTERNAL_TESTS rsalz> fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER rsalz> fuzz-afl [default] OPENSSL_NO_FUZZ_AFL rsalz> heartbeats [default] OPENSSL_NO_HEARTBEATS rsalz> md2 [default] OPENSSL_NO_MD2 (skip crypto/md2) rsalz> msan [default] OPENSSL_NO_MSAN rsalz> rc5 [default] OPENSSL_NO_RC5 (skip crypto/rc5) rsalz> sctp [default] OPENSSL_NO_SCTP rsalz> ssl-trace [default] OPENSSL_NO_SSL_TRACE rsalz> tls13downgrade [default] OPENSSL_NO_TLS13DOWNGRADE rsalz> ubsan [default] OPENSSL_NO_UBSAN rsalz> unit-test [default] OPENSSL_NO_UNIT_TEST rsalz> weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS rsalz> zlib [default] rsalz> zlib-dynamic [default] rsalz> ssl3 [default] OPENSSL_NO_SSL3 rsalz> ssl3-method [default] OPENSSL_NO_SSL3_METHOD rsalz> rsalz> Config target attributes: rsalz> rsalz> AR => "ar", rsalz> ARFLAGS => "r", rsalz> CC => "gcc", rsalz> CFLAGS => "-Wall -O3", rsalz> CXX => "g++", rsalz> CXXFLAGS => "-Wall -O3", rsalz> HASHBANGPERL => "/usr/bin/env perl", rsalz> RANLIB => "ranlib", rsalz> RC => "windres", rsalz> aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s aesni-mb-x86_64.s", rsalz> aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o", rsalz> apps_aux_src => "", rsalz> apps_init_src => "", rsalz> apps_obj => "", rsalz> bf_asm_src => "bf_enc.c", rsalz> bf_obj => "bf_enc.o", rsalz> bn_asm_src => "asm/x86_64-gcc.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s", rsalz> bn_obj => "asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o", rsalz> bn_ops => "SIXTY_FOUR_BIT_LONG", rsalz> build_file => "Makefile", rsalz> build_scheme => [ "unified", "unix" ], rsalz> cast_asm_src => "c_enc.c", rsalz> cast_obj => "c_enc.o", rsalz> cflags => "-pthread -m64", rsalz> chacha_asm_src => "chacha-x86_64.s", rsalz> chacha_obj => "chacha-x86_64.o", rsalz> cmll_asm_src => "cmll-x86_64.s cmll_misc.c", rsalz> cmll_obj => "cmll-x86_64.o cmll_misc.o", rsalz> cppflags => "", rsalz> cpuid_asm_src => "x86_64cpuid.s", rsalz> cpuid_obj => "x86_64cpuid.o", rsalz> cxxflags => "-std=c++11 -pthread -m64", rsalz> defines => [ ], rsalz> des_asm_src => "des_enc.c fcrypt_b.c", rsalz> des_obj => "des_enc.o fcrypt_b.o", rsalz> disable => [ ], rsalz> dso_extension => ".so", rsalz> dso_scheme => "dlfcn", rsalz> ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s x25519-x86_64.s", rsalz> ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o", rsalz> enable => [ "afalgeng" ], rsalz> ex_libs => "-ldl -pthread", rsalz> exe_extension => "", rsalz> includes => [ ], rsalz> keccak1600_asm_src => "keccak1600-x86_64.s", rsalz> keccak1600_obj => "keccak1600-x86_64.o", rsalz> lflags => "", rsalz> lib_cflags => "", rsalz> lib_cppflags => "-DOPENSSL_USE_NODELETE -DL_ENDIAN", rsalz> lib_defines => [ ], rsalz> md5_asm_src => "md5-x86_64.s", rsalz> md5_obj => "md5-x86_64.o", rsalz> modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s", rsalz> modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o", rsalz> module_cflags => "-fPIC", rsalz> module_cxxflags => "", rsalz> module_ldflags => "-Wl,-znodelete -shared -Wl,-Bsymbolic", rsalz> multilib => "64", rsalz> padlock_asm_src => "e_padlock-x86_64.s", rsalz> padlock_obj => "e_padlock-x86_64.o", rsalz> perlasm_scheme => "elf", rsalz> poly1305_asm_src => "poly1305-x86_64.s", rsalz> poly1305_obj => "poly1305-x86_64.o", rsalz> rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s", rsalz> rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o", rsalz> rc5_asm_src => "rc5_enc.c", rsalz> rc5_obj => "rc5_enc.o", rsalz> rmd160_asm_src => "", rsalz> rmd160_obj => "", rsalz> sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s sha1-mb-x86_64.s sha256-mb-x86_64.s", rsalz> sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o", rsalz> shared_cflag => "-fPIC", rsalz> shared_defflag => "-Wl,--version-script=", rsalz> shared_defines => [ ], rsalz> shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)", rsalz> shared_extension_simple => ".so", rsalz> shared_ldflag => "-Wl,-znodelete -shared -Wl,-Bsymbolic", rsalz> shared_rcflag => "", rsalz> shared_sonameflag => "-Wl,-soname=", rsalz> shared_target => "linux-shared", rsalz> thread_defines => [ ], rsalz> thread_scheme => "pthreads", rsalz> unistd => "", rsalz> uplink_aux_src => "", rsalz> uplink_obj => "", rsalz> wp_asm_src => "wp-x86_64.s", rsalz> wp_obj => "wp-x86_64.o", rsalz> rsalz> Recorded environment: rsalz> rsalz> AR = rsalz> ARFLAGS = rsalz> AS = rsalz> ASFLAGS = rsalz> BUILDFILE = rsalz> CC = rsalz> CFLAGS = rsalz> CPP = rsalz> CPPDEFINES = rsalz> CPPFLAGS = rsalz> CPPINCLUDES = rsalz> CROSS_COMPILE = rsalz> CXX = rsalz> CXXFLAGS = rsalz> HASHBANGPERL = rsalz> LD = rsalz> LDFLAGS = rsalz> LDLIBS = rsalz> MT = rsalz> MTFLAGS = rsalz> OPENSSL_LOCAL_CONFIG_DIR = rsalz> PERL = rsalz> RANLIB = rsalz> RC = rsalz> RCFLAGS = rsalz> RM = rsalz> WINDRES = rsalz> __CNF_CFLAGS = rsalz> __CNF_CPPDEFINES = rsalz> __CNF_CPPFLAGS = rsalz> __CNF_CPPINCLUDES = rsalz> __CNF_CXXFLAGS = rsalz> __CNF_LDFLAGS = rsalz> __CNF_LDLIBS = rsalz> rsalz> Makevars: rsalz> rsalz> AR = ar rsalz> ARFLAGS = r rsalz> CC = gcc rsalz> CFLAGS = -Wall -O3 rsalz> CPPDEFINES = rsalz> CPPFLAGS = rsalz> CPPINCLUDES = rsalz> CXX = g++ rsalz> CXXFLAGS = -Wall -O3 rsalz> HASHBANGPERL = /usr/bin/env perl rsalz> LDFLAGS = rsalz> LDLIBS = rsalz> PERL = /usr/bin/perl rsalz> RANLIB = ranlib rsalz> RC = windres rsalz> rsalz> NOTE: These variables only represent the configuration view. The build file rsalz> template may have processed these variables further, please have a look at the rsalz> build file for more exact data: rsalz> Makefile rsalz> rsalz> build file: rsalz> rsalz> Makefile rsalz> rsalz> build file templates: rsalz> rsalz> Configurations/common0.tmpl rsalz> Configurations/unix-Makefile.tmpl rsalz> Configurations/common.tmpl rsalz> ; From rsalz at akamai.com Tue Jul 24 17:36:49 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 24 Jul 2018 17:36:49 +0000 Subject: [openssl-project] master is broken? In-Reply-To: <20180724.193306.328060713509212733.levitte@openssl.org> References: <21FE7178-6410-48F4-AD17-152454DE00B5@akamai.com> <20180724.193306.328060713509212733.levitte@openssl.org> Message-ID: ; 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 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .). BEGIN failed--compilation aborted. You need Perl 5. exit 1 ; perl -v This is perl 5, version 18, subversion 2 (v5.18.2) built for x86_64-linux-gnu-thread-multi (with 52 registered patches, see perl -V for more detail) Copyright 1987-2013, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. ; ?On 7/24/18, 1:33 PM, "Richard Levitte" wrote: PERL5OPT=-MCarp::Always ./config From levitte at openssl.org Tue Jul 24 17:42:42 2018 From: levitte at openssl.org (Richard Levitte) Date: Tue, 24 Jul 2018 19:42:42 +0200 (CEST) Subject: [openssl-project] master is broken? In-Reply-To: References: <21FE7178-6410-48F4-AD17-152454DE00B5@akamai.com> <20180724.193306.328060713509212733.levitte@openssl.org> Message-ID: <20180724.194242.421613354755642920.levitte@openssl.org> 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... In message on Tue, 24 Jul 2018 17:36:49 +0000, "Salz, Rich" said: rsalz> ; env | grep PERL rsalz> ; PERL5OPT=-MCarp::Always ./config rsalz> Operating system: x86_64-whatever-linux2 rsalz> 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 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .). rsalz> BEGIN failed--compilation aborted. rsalz> You need Perl 5. rsalz> exit 1 rsalz> ; perl -v rsalz> rsalz> This is perl 5, version 18, subversion 2 (v5.18.2) built for x86_64-linux-gnu-thread-multi rsalz> (with 52 registered patches, see perl -V for more detail) rsalz> rsalz> Copyright 1987-2013, Larry Wall rsalz> rsalz> Perl may be copied only under the terms of either the Artistic License or the rsalz> GNU General Public License, which may be found in the Perl 5 source kit. rsalz> rsalz> Complete documentation for Perl, including FAQ lists, should be found on rsalz> this system using "man perl" or "perldoc perl". If you have access to the rsalz> Internet, point your browser at http://www.perl.org/, the Perl Home Page. rsalz> rsalz> ; rsalz> rsalz> ?On 7/24/18, 1:33 PM, "Richard Levitte" wrote: rsalz> rsalz> PERL5OPT=-MCarp::Always ./config rsalz> rsalz> _______________________________________________ rsalz> openssl-project mailing list rsalz> openssl-project at openssl.org rsalz> https://mta.openssl.org/mailman/listinfo/openssl-project From rsalz at akamai.com Tue Jul 24 17:50:50 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 24 Jul 2018 17:50:50 +0000 Subject: [openssl-project] master is broken? In-Reply-To: <20180724.194242.421613354755642920.levitte@openssl.org> References: <21FE7178-6410-48F4-AD17-152454DE00B5@akamai.com> <20180724.193306.328060713509212733.levitte@openssl.org> <20180724.194242.421613354755642920.levitte@openssl.org> Message-ID: ?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. Does this add a new dependency for openssl? Maybe reconsider the approach -- Things seemed acceptable before the latest change. Or maybe print STDERR ? ; sudo cpan install perl-Carp-Always Loading internal null logger. Install Log::Log4perl for logging messages CPAN: Storable loaded ok (v2.41) Reading '/home/rsalz/.cpan/Metadata' Database was generated on Tue, 24 Jul 2018 17:17:02 GMT ; No what? Running "./config -d" still gives the same error message output and this: ; 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 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .). BEGIN failed--compilation aborted. You need Perl 5. exit 1 ; From levitte at openssl.org Tue Jul 24 17:54:58 2018 From: levitte at openssl.org (Richard Levitte) Date: Tue, 24 Jul 2018 19:54:58 +0200 (CEST) Subject: [openssl-project] Speaking of broken master, have a look at Travis Message-ID: <20180724.195458.1200037605141780475.levitte@openssl.org> The master branch doesn't seem to be doing too well currently: https://travis-ci.org/openssl/openssl/branches The issue appears to be with the BoringSSL tests: https://travis-ci.org/openssl/openssl/jobs/407676514 I see segfaults: ... go test: FAILED (ServerNameExtensionServer-TLS1) go test: unexpected failure: local error 'read tcp4 127.0.0.1:41729->127.0.0.1:60574: read: connection reset by peer', child error 'signal: segmentation fault (core dumped)', stdout: go test: go test: stderr: go test: go test: ... go test: FAILED (ServerNameExtensionServer-TLS11) go test: unexpected failure: local error 'read tcp4 127.0.0.1:46797->127.0.0.1:57250: read: connection reset by peer', child error 'signal: segmentation fault (core dumped)', stdout: go test: go test: stderr: go test: go test: ... go test: FAILED (ServerNameExtensionServer-TLS12) go test: unexpected failure: local error 'read tcp4 127.0.0.1:41948->127.0.0.1:49698: read: connection reset by peer', child error 'signal: segmentation fault (core dumped)', stdout: go test: go test: stderr: go test: go test: ... Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Tue Jul 24 18:00:01 2018 From: levitte at openssl.org (Richard Levitte) Date: Tue, 24 Jul 2018 20:00:01 +0200 (CEST) Subject: [openssl-project] master is broken? In-Reply-To: References: <20180724.194242.421613354755642920.levitte@openssl.org> Message-ID: <20180724.200001.157476181689304073.levitte@openssl.org> In message on Tue, 24 Jul 2018 17:50:50 +0000, "Salz, Rich" said: rsalz> rsalz> rsalz> ?On 7/24/18, 1:42 PM, "Richard Levitte" wrote: rsalz> rsalz> Would you mind installing it? The package is called rsalz> libcarp-always-perl on Debian and derivates, and if my RPM search fu rsalz> isn't entirely off, the corresponding RPM package is perl-Carp-Always rsalz> rsalz> Or install with cpan... rsalz> rsalz> Okay. Does this add a new dependency for openssl? Maybe rsalz> reconsider the approach -- Things seemed acceptable before the rsalz> latest change. Or maybe print STDERR ? No, I'm asking you to install a module that can help us figure out the problem, to be used temporarly. I'm not making OpenSSL dependent on Carp::Always. rsalz> ; sudo cpan install perl-Carp-Always Ah, I should have told you. The correct invocation is: sudo cpan Carp::Always -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Tue Jul 24 18:05:35 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 24 Jul 2018 18:05:35 +0000 Subject: [openssl-project] master is broken? In-Reply-To: <20180724.200001.157476181689304073.levitte@openssl.org> References: <20180724.194242.421613354755642920.levitte@openssl.org> <20180724.200001.157476181689304073.levitte@openssl.org> Message-ID: <84E6620A-E6BC-4F6E-A282-B46841B6D77E@akamai.com> sudo cpan Carp::Always I did this. Same results for config and the PERLOPT setting. From kurt at roeckx.be Tue Jul 24 18:34:28 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 24 Jul 2018 20:34:28 +0200 Subject: [openssl-project] Speaking of broken master, have a look at Travis In-Reply-To: <20180724.195458.1200037605141780475.levitte@openssl.org> References: <20180724.195458.1200037605141780475.levitte@openssl.org> Message-ID: <20180724183427.GA12166@roeckx.be> On Tue, Jul 24, 2018 at 07:54:58PM +0200, Richard Levitte wrote: > ... > go test: FAILED (ServerNameExtensionServer-TLS1) > go test: unexpected failure: local error 'read tcp4 127.0.0.1:41729->127.0.0.1:60574: read: connection reset by peer', child error 'signal: segmentation fault (core dumped)', stdout: This is caused by https://github.com/openssl/openssl/pull/6378 Kurt From levitte at openssl.org Tue Jul 24 20:18:29 2018 From: levitte at openssl.org (Richard Levitte) Date: Tue, 24 Jul 2018 22:18:29 +0200 (CEST) Subject: [openssl-project] master is broken? In-Reply-To: <84E6620A-E6BC-4F6E-A282-B46841B6D77E@akamai.com> References: <20180724.200001.157476181689304073.levitte@openssl.org> <84E6620A-E6BC-4F6E-A282-B46841B6D77E@akamai.com> Message-ID: <20180724.221829.2120175036697741014.levitte@openssl.org> In message <84E6620A-E6BC-4F6E-A282-B46841B6D77E at akamai.com> on Tue, 24 Jul 2018 18:05:35 +0000, "Salz, Rich" said: rsalz> sudo cpan Carp::Always rsalz> rsalz> I did this. Same results for config and the PERLOPT setting. For everyone's information, the breakage was really just rogue output. The death handler was badly written, but got fixed up with this PR: https://github.com/openssl/openssl/pull/6776 Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kaduk at mit.edu Wed Jul 25 01:46:51 2018 From: kaduk at mit.edu (Benjamin Kaduk) Date: Tue, 24 Jul 2018 20:46:51 -0500 Subject: [openssl-project] Speaking of broken master, have a look at Travis In-Reply-To: <20180724183427.GA12166@roeckx.be> References: <20180724.195458.1200037605141780475.levitte@openssl.org> <20180724183427.GA12166@roeckx.be> Message-ID: <20180725014650.GN92448@kduck.kaduk.org> On Tue, Jul 24, 2018 at 08:34:28PM +0200, Kurt Roeckx wrote: > On Tue, Jul 24, 2018 at 07:54:58PM +0200, Richard Levitte wrote: > > ... > > go test: FAILED (ServerNameExtensionServer-TLS1) > > go test: unexpected failure: local error 'read tcp4 127.0.0.1:41729->127.0.0.1:60574: read: connection reset by peer', child error 'signal: segmentation fault (core dumped)', stdout: > > This is caused by https://github.com/openssl/openssl/pull/6378 Yup, Andy pointed it out. I've tried to get a local setup with the boring tests, but need to put a bit more time into it, it seems. At least there's not an IESG telechat this week... -Ben From matt at openssl.org Sat Jul 28 08:50:29 2018 From: matt at openssl.org (Matt Caswell) Date: Sat, 28 Jul 2018 09:50:29 +0100 Subject: [openssl-project] To distribute just the repo file, or the result of 'make dist'? In-Reply-To: <20180724.155055.721916182736074624.levitte@openssl.org> References: <20180724.140846.1287409772932331226.levitte@openssl.org> <20180724122839.GA2433@roeckx.be> <20180724.155055.721916182736074624.levitte@openssl.org> Message-ID: <25df2b47-8c69-e93c-a910-60e5e2fd0551@openssl.org> On 24/07/18 14:50, Richard Levitte wrote: > In message <20180724122839.GA2433 at roeckx.be> on Tue, 24 Jul 2018 14:28:40 +0200, Kurt Roeckx said: > > kurt> On Tue, Jul 24, 2018 at 02:08:46PM +0200, Richard Levitte wrote: > kurt> > > kurt> > The original intention (way back, I think we're even talking SSLeay > kurt> > time here, but at the very least pre-1.0.0 time) was to make a tarball > kurt> > that can be built directly with just a 'make' on any Unix box and > kurt> > without requiring perl. > kurt> > kurt> I don't see how that could work our current system. As far as I > kurt> know, it's actually confired for a system, and it will not work > kurt> properly on an other. It would just work on the same system as > kurt> that we ran config on. > > Hmm? The dist target (Configurations/dist.conf) creates a *very* > generic Makefile with no system specific files. It assumes LP32 and > very generic C compiler command line. It doesn't support assembler > modules, threads or shared libraries... that cuts away quite a lot of Which means it is essentially useless for most purposes. > system dependencies. The only thing that's needed to make the > resulting directory tree free of the need for perl is 'make > build_all_generated'. > > kurt> > 1. Don't release pre-configured tarballs. This is a very simple > kurt> > thing to do, all we have to do is use 'make tar' to create > kurt> > tarballs instead of 'make dist'. We could remove the dist target > kurt> > entirely while we're at it. > kurt> > kurt> This makes most sense to me. > > Yes, it does to me as well, especially considering we're encouraging > everyone to configure anyway. > I agree. Matt