On Wed, Oct 12, 2022 at 03:35:19PM +0200, Richard Levitte wrote:
> Topic: Provider selection and handling for SHA1 and RIPEMD160 should be
> identical
>given the current understanding of algorithm specific security issues.
Shouldn't real-world usage be taken into account. SHA1 is widely
Is there an open pull request for this?
> On Feb 23, 2021, at 8:21 AM, Tomas Mraz wrote:
>
> topic: The RSA_SSLV23_PADDING and related functions should be
> completely removed from OpenSSL 3.0 code.
>
> comment: The padding mode and the related functions (which are already
> deprecated in the c
On Thu, Mar 26, 2020 at 11:33:40PM +, Matt Caswell wrote:
> On 26/03/2020 23:15, Viktor Dukhovni wrote:
> > On Thu, Mar 26, 2020 at 09:13:32PM +0100, Bernd Edlinger wrote:
> >
> >> we got into this situation because everything moves so quickly,
> >> why d
On Thu, Mar 26, 2020 at 09:13:32PM +0100, Bernd Edlinger wrote:
> we got into this situation because everything moves so quickly,
> why does everyone here think we should move even faster now?
>
> What is the reason for this?
We've published a bug-fix release (1.1.1e) that's liable to cause more
> On Feb 22, 2020, at 4:53 AM, Richard Levitte wrote:
>
> Something that could be done is to take all those aged commands and
> rewrite them as wrappers for genpkey, pkey and pkeyutl. Simply create
> and populate a new argv and call genpkey_main(), pkey_main() or
> pkeyutl_main().
Agreed, that
On Sat, Feb 22, 2020 at 12:51:17AM +0100, Kurt Roeckx wrote:
> > (I just realised that what the CHANGES entry says is that
> > dhparam/dsaparam are deprecated in favour of pkeyparam - but actually I
> > think the equivalent functionality is more split between genpkey and
> > pkeyparam)
>
> Some e
On Fri, Feb 21, 2020 at 11:00:10PM +, Matt Caswell wrote:
> dhparam itself has been deprecated. For that reason we are not
> attempting to rewrite it to use non-deprecated APIs. The informed
> decision we have made about DH_check use in dhparam is to not build the
> whole application in a no-d
On Sun, Jan 19, 2020 at 12:26:06PM +0100, Kurt Roeckx wrote:
> The only thing that we support currently that makes sense as a
> default is -5 (sha256) and -6 (sha512). I suggest you go with -6.
I concur, FWIW this is the default password hash for my FreeBSD 12
server, so it is not a Linux-only co
On Fri, Jan 17, 2020 at 04:31:06PM +1000, Dr Paul Dale wrote:
> There are two functions (DES_crypt and DES_fcrypt) which implement the
> old crypt(3) password algorithm. Once these are deprecated, they will
> no longer be reachable via EVP. The confounding point is that they
> aren’t quite DES —
My abstain vote was a carefully considered neutral stance backed
by many paragraphs of rationale.
The gist of which is that given that the decision to load or not
the provider is in the configuration file, the party ultimately
making the decision is whoever packages the software, not the
OpenSSL p
> On Nov 14, 2019, at 9:15 AM, Matt Caswell wrote:
>
> "No existing public interface can be removed until its replacement has
> been in place in an LTS stable release. The original interface must also
> have been documented as deprecated for at least 5 years. A public
> interface is any function,
On Thu, Nov 14, 2019 at 08:41:57AM +, Matt Caswell wrote:
> I think that we should not add them to 1.1.1 without also adding them to 3.0.
Yes.
> OTOH if you have a 1.0.2 application that uses these things then not having
> them would represent a barrier to moving off of 1.0.2. And it doesn't
+1 (and more) to the below!
> On Sep 4, 2019, at 10:15 AM, David Woodhouse wrote:
>
> I'd note that the question of *versioning* mechanisms is a very very
> special case of "when to deprecate stuff". So much so as to almost make
> it a completely separate question altogether.
>
> My own favouri
On Wed, Sep 04, 2019 at 02:43:34PM +0200, Tomas Mraz wrote:
> > The dispute in PR https://github.com/openssl/openssl/pull/7853 has
> > made it quote obvious that we have some very different ideas on when
> > and why we should or shouldn't deprecate stuff.
> >
> > What does deprecation mean? Esse
> On Jul 30, 2019, at 10:02 PM, Dr Paul Dale wrote:
>
> The #9454 description includes thread sanitisizer logs showing different lock
> orderings — this has the potential to dead lock. Agreed with Rich that
> giving up the lock would make sense, but I don’t see a way for this to be
> easily d
On Mon, Jul 15, 2019 at 02:27:44PM +, Salz, Rich wrote:
> >>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.
>
> On Jul 10, 2019, at 10:37 AM, Dmitry Belyavsky wrote:
>
> Formally I am a contributor with a signed CLA.
> I took a code definitely permitting any usage without any feedback, slightly
> modified it (at least by openssl-format-source and splitting between header
> and source), and submitted i
On Thu, Jun 20, 2019 at 03:39:10PM +0100, Matt Caswell wrote:
> PR 9199 incorporates the C punycode implementation from RFC3492:
>
> https://github.com/openssl/openssl/pull/9199
>
> The RFC itself has this section in it:
>
> B. Disclaimer and license
>
>Regarding this entire document or an
On Fri, Jun 14, 2019 at 01:41:51PM +1000, Dr Paul Dale wrote:
> I’m behind ditching the function identifier #defines but not their text names.
Good to hear.
> #define ERR_raise_error ERR_raise_error_internal(__FILE__, __LINE__, __FUNC__)
Well, __FUNC__ is entirely non-standard, and __func__ is
On Wed, Jun 12, 2019 at 05:51:44AM +0200, Richard Levitte wrote:
> A discussion point in that PR is whether it's still interesting to
> keep information on the system function/callback that was called when
> we're reporting a system error, i.e. this type of error report:
>
> SYSerr(SYS_F_FSTA
On Wed, Jun 12, 2019 at 10:02:25AM +0100, Matt Caswell wrote:
> OTOH I do find them quite helpful from a debugging perspective, e.g. when
> people
> send in questions along the lines of "I got this error what does it mean/how
> do
> I fix it" - although what is actually useful is usually the fun
> On Jun 8, 2019, at 6:18 AM, Kurt Roeckx wrote:
>
> And the people that make those platforms have no clue and
> no time to care about that. It works, ship it. If we don't
> make clear it's broken, it's not going to get fixed.
Yes, but not at the cost of collateral damage to properly designed
wo
> On Jun 7, 2019, at 7:24 PM, Kurt Roeckx wrote:
>
> That's all very nice, but nobody is going to run that.
They also don't have to upgrade their kernel, or deploy new
versions of OpenSSL. If platform release engineers don't
deploy core services that ensure reliably CSPRNG seeding,
then their p
On Sat, Jun 08, 2019 at 12:54:36AM +0200, Kurt Roeckx wrote:
> On Fri, Jun 07, 2019 at 03:37:07PM -0400, Viktor Dukhovni wrote:
> > > On Jun 7, 2019, at 3:25 PM, Kurt Roeckx wrote:
> > >
> > > For older kernels you install rng-tools that feeds the hwrng in
> >
> On Jun 7, 2019, at 3:25 PM, Kurt Roeckx wrote:
>
> For older kernels you install rng-tools that feeds the hwrng in
> the kernel.
Which works for me, and is pretty much the point I'm trying to make.
Then, read /dev/random once early at boot, and do nothing special
libcrypto (safely use /dev/ura
> On Jun 7, 2019, at 2:41 PM, Kurt Roeckx wrote:
>
>> This is not the sort of thing to bolt into the kernel, but is not
>> unreasonable for systemd and the like.
>
> The kernel actually already does this in recent versions, if
> configured to do it.
We're talking about what to do with for older
> On Jun 7, 2019, at 2:11 PM, Dr. Matthias St. Pierre
> wrote:
>
>> The init system would
>> need to create this kind of service, and then all software not using
>> getentropy()/getrandom() would need to depend on that service. It
>
> FWIW: systemd already has a service for saving and restoring
On Fri, Jun 07, 2019 at 11:09:45AM +0200, Matthias St. Pierre wrote:
> See the discussion on openssl-users:
>
> https://mta.openssl.org/pipermail/openssl-users/2019-May/010585.html
> https://mta.openssl.org/pipermail/openssl-users/2019-May/010593.html
> https://mta.openssl.org/pipermail/openssl-u
On Thu, May 23, 2019 at 03:45:48PM +0100, Matt Caswell wrote:
> IMO, no.
I also don't see a need for this at present, and it is not clear
that there are enough active part-time reviewers in place to keep
up with commits from the fellows in a timely manner.
--
Viktor.
> On Jan 27, 2019, at 5:33 AM, Tim Hudson wrote:
>
> Tim - I think inline functions in public header files simply shouldn't be
> present.
I think they have their place, and we should try to make them more portable
to less capable toolchains as needed.
--
Viktor.
_
> On Jan 23, 2019, at 12:42 PM, David Benjamin wrote:
>
> (a) Debugging hooks for tracing, often copied from the openssl binary.
> (b) As a callback to know when the handshake (in the RFC8446 sense described
> above, not the OpenSSL sense) is done, sensitive to SSL_CB_HANDSHAKE_DONE.
> (c) As a
> On Jan 22, 2019, at 2:06 PM, Adam Langley wrote:
>
> (This is another installment of our experiences with deploying the
> RFC-final TLS 1.3—previous messages: [1][2]. We share these with the
> community to hopefully avoid other people hitting the same issues.)
>
> [...]
>
> However, OpenSSL
With automatic library initialization in OpenSSL 1.1.0 and later,
settings from the system-wide "openssl.cnf" file are automatically
loaded and may in turn cause various "modules" to be initialized.
For example, with:
openssl.conf:
openssl_conf= system-wide-modules
#
[sy
On Wed, Nov 14, 2018 at 01:27:17PM +, Matt Caswell wrote:
> There are now no open PRs/issues with the 1.1.1a milestone so I think we
> should
> go ahead and do a release. The question is when? I propose next Tuesday
> (20th),
> with releases of 1.1.0 and 1.0.2 on the same day. It's been a wh
On Mon, Oct 15, 2018 at 06:56:06PM +0100, Matt Caswell wrote:
> > What do you make of the
> > idea of making it possible for servers to accept downgrades (to some
> > floor protocol version or all supported versions)?
>
> I'm really not keen on that idea at all.
I understand the healthy skeptici
> On Oct 15, 2018, at 9:19 AM, Matt Caswell wrote:
>
>> Early, partial reports of the cause seem to indicate that the sending
>> side was using OpenSSL with:
>>
>> SSL_CTX_set_mode(ctx, SSL_MODE_SEND_FALLBACK_SCSV);
>>
>> seemingly despite no prior handshake failure,
>
> Are you sure a
On Thu, Oct 11, 2018 at 07:03:21PM -0500, Benjamin Kaduk wrote:
> I would guess that the misbehaving clients are early openssl betas
> that receive the real TLS 1.3 version and then try to interpret
> as whatever draft versino they actually implemnet.
Early, partial reports of the cause seem to i
Apparently, some SMTP clients set fallback_scsv when doing TLS 1.2
with Postfix servers using OpenSSL 1.1.1. Not yet clear whether
they tried TLS 1.3 first and failed, or just sent the SCSV out of
the blue...
See attached. If this is a common problem, it might be useful to
have a control that t
> On Sep 25, 2018, at 9:51 AM, Matt Caswell wrote:
>
> 5.0.0
> 5.0.1 (bug fix)
> 5.1.0 (add accessor)
> 6.0.0 (new feature)
> 6.0.1 (bug fix)
> 5.1.1 (bug fix)6.0.2 (bug fix)
> 5.2.1 (add accessor)
> 6.1.0 (add accessor)
> On Sep 22, 2018, at 12:50 AM, Tim Hudson wrote:
>
> The impact of the breaking change on anyone actually following our documented
> encoding cannot.
> i.e. openssh as one example Richard pointed out.
The only use of OPENSSL_VERSION_NUMBER bits in OpenSSH (which is not yet ported
to
1.1.x
> On Sep 22, 2018, at 12:59 AM, Richard Levitte wrote:
>
> So in summary, do we agree on this, and that it's a good path forward?
>
> - semantic versioning scheme good, we should adopt it.
> - we need to agree on how to translate that in code.
> - we need to stop fighting about history.
Yes.
> On Sep 21, 2018, at 9:28 PM, Tim Hudson wrote:
>
> That parsing of history I think is at best a stretch and not supportable and
> also not what our users think.
This isn't a mathematical theorem or even a legal debate.
We should do what makes the most sense going forward.
Richar proposes, an
> On Sep 21, 2018, at 4:55 PM, Richard Levitte wrote:
>
> I think we need to get rid of OPENSSL_VERSION_NUMBER.
Absolutely not. That's the one thing we must keep, and keep monotone
so that applications continue to compile and build.
Sure we need to communicate our ABI/API stability policies
> On Sep 21, 2018, at 4:01 PM, Richard Levitte wrote:
>
> For pre-processing, that might be different, I have no clue how people
> figure out the exact number to compare OPENSSL_VERSION_NUMBER... I
> assume, though, that they follow the path of least resistance and
> simply pick the current numb
> On Sep 21, 2018, at 12:50 PM, Tim Hudson wrote:
> If that is the case then our current practice of allowing ABI breakage with
> minor release changes (the middle number we document as the minor release
> number)
> has to change.
CORRECTION: As advertised when 1.0.0 first came out, and rep
> On Sep 21, 2018, at 12:14 PM, Matt Caswell wrote:
>
> I support Richard's proposal with an epoch of 1.
> Grudgingly I would accept an epoch in the 3-8 range.
> I would oppose an epoch of 2.
I can live with that, though it might mean that a minority of
applications will interpret (based on o
> On Sep 21, 2018, at 11:56 AM, Tim Hudson wrote:
>
> What I was suggesting is that we don't need to break the current encoding at
> all.
Not changing the encoding has a downside.
* The bits that represent ABI stability would shift from the
2nd/3rd nibbles to just the first nibble.
* We
> On Sep 21, 2018, at 11:40 AM, Tim Hudson wrote:
>
> That is something I wouldn't suggest makes sense as an approach - to change
> the tarfile name and leave all the internals the same achieves nothing.
And that's not the proposal. The proposal is that the new major number
is 2 (or 3 if so
> On Sep 21, 2018, at 11:27 AM, Tim Hudson wrote:
>
> No it isn't - as you note that isn't a valid mapping - 1.0 isn't a semantic
> version and there is no such thing as a fix number,
> You get three concepts and then on top of that the pre-release and the
> build-metadata.
>
> Semantic ver
> On Sep 21, 2018, at 11:16 AM, Viktor Dukhovni
> wrote:
>
> I'm afraid that's where you're simply wrong. Ever since 1.0.0, OpenSSL
> has promised (and I think delivered) ABI stability for the *minor* version
> and feature stability (bug fixes only) for the
> On Sep 21, 2018, at 11:13 AM, Matthias St. Pierre
> wrote:
>
> I like Richard's approach (with the '8' or another number) and I don't think
> it is
> contradicting semantic versioning. Maybe a good compromise between your two
> opposing views would be to make the encoding irrelevant to o
> On Sep 21, 2018, at 11:00 AM, Tim Hudson wrote:
>
> If you repeat that in semantic versioning concepts just using the labels for
> mapping you get:
> - what is the major version number - the answer is clearly "1".
> - what is the minor version number - the answer is clearly "0"
> - what is
> On Sep 21, 2018, at 10:07 AM, Tim Hudson wrote:
>
> And the output you get:
>
> 0x10102000
The trouble is that existing software expects to potential ABI changes
resulting from changes in the 2nd and 3rd nibbles, and if the major
version is just in the first nibble, our minor version chan
> On Sep 21, 2018, at 9:35 AM, Richard Levitte wrote:
>
> In that case, we should probably just thrown away
> OPENSSL_VERSION_NUMBER.
Sorry, that must not t happen and there's no need. My sense is that Tim
may end up "in the rough" on this issue, so unless there's more evidence
of support for
I support Richard's numeric scheme as proposed, with one small change.
I think that setting the epoch to 8 to set the high bit is neither
necessary nor wise. Though the numeric version constant should be
manifestly unsigned (UL suffix not L), and having the top 3 nibbles
for the "effective" major
> On Sep 6, 2018, at 6:25 PM, Matt Caswell wrote:
>
> I'm not keen on that. What do others think?
No objections to issuing a release. We're unlikely to have to change the
API/ABI or feature set based on further beta feedback. Any late bugs can
be fixed in 1.1.1a, and unless they trigger CVE
> On Aug 15, 2018, at 11:50 AM, Matt Caswell wrote:
>>
>> I think this counts as a regression, the client should notice that
>> it implicitly disabled TLS 1.3, and therefore not react to the
>> server's version sentinel by aborting the connection. Thoughts?
>>
>
> Hmm. Yes we should probabl
When I configure a client with a legacy TLS 1.2 protocol exclusion,
e.g. by setting SSL_OP_NO_TLSv1_2 (rather than the new min/max
version interface), as a result of the new TLS 1.3 protocol
suport configurations that previously negotiated "up to" TLS 1.1,
now fail when communicating with a TLS 1.3
On Mon, Aug 13, 2018 at 03:07:02PM +0100, Matt Caswell wrote:
> - I think the ca app usability improvements for EdDSA (PR 6901) should
> go in (I have initial approval, awaiting a reconfirm from Viktor)
I already did that. Go ahead and merge.
--
Viktor.
I just ran into: https://abi-laboratory.pro/index.php?view=timeline&l=openssl
Perhaps you've all seen this site already, but if not, enjoy!
FWIW, OpenSSL 1.1.1/master are looking fine. Just some SM2-related
symbol churn, which does not affect the stable ABI.
--
Viktor.
_
On Sat, Aug 11, 2018 at 01:50:07PM +, Salz, Rich wrote:
> FYI. Quietly ignoring fractional seconds makes sense to me.
Ditto.
--
Viktor.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/
On Thu, Aug 09, 2018 at 02:23:07PM -0700, Paul Dale wrote:
> > Real code often doesn't check return values. Even ours. :(
>
> Could we consider adding a lot more __owur tags to functions to encourage
> this?
>
> As an API change it would have to wait for a major release.
This is sometimes a g
On Thu, Aug 09, 2018 at 07:12:18PM +0200, Richard Levitte wrote:
> viktor> X509 *x;
> viktor> STACK_OF(X509) *s;
> viktor>
> viktor> ...
> viktor> /* Allocate 's' and initialize with x as first element */
> viktor> if (sk_X509_push(s = sk_X509_new(NULL), x) < 0) {
>
On Thu, Aug 09, 2018 at 06:40:14PM +0200, Richard Levitte wrote:
> In message <20180809162245.gd14...@straasha.imrryr.org> on Thu, 9 Aug 2018
> 12:22:45 -0400, Viktor Dukhovni said:
>
> openssl-users> It needs to be possible to recompile and run without auditing
> co
On Thu, Aug 09, 2018 at 05:53:11PM +0200, Richard Levitte wrote:
> I think we need to be a bit more nuanced in our views. Bug fixes are
> potentially behaviour changes (for example, I recently got through a
> PR that added a stricter check of EVP_PKEY_asn1_new() input; see #6880
> (*)).
We went
> On Aug 9, 2018, at 9:49 AM, Salz, Rich wrote:
>
> This is another reason why I am opposed to NULL checks.
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. We must
avoid API changes
Don't know whether everyone here also reads openssl-users, so to recap,
Robert Moskowitz reports considerable frustration
as a result of "default_md = sha256" being incompatible with Ed25519
(and Ed448). He's working around this with "-md null" sprinkled about
liberally, but it is not especially
> On Aug 8, 2018, at 6:19 AM, Tim Hudson wrote:
>
> However in the context of removing such checks - that we should not be doing
> - the behaviour of the APIs in this area should not be changed
Should not be changed period. Even across major release boundaries.
This is not an ABI compatibil
> On Jun 12, 2018, at 6:56 PM, Richard Levitte wrote:
>
> Some implementations of the iconv library take the empty string as
> the locale-specific encoding, but that is in no way universal, and
> isn't specified in the standard:
>
> http://pubs.opengroup.org/onlinepubs/009695399/functions/ico
> On Jun 12, 2018, at 3:39 PM, Richard Levitte wrote:
>
>> The flags I'd like to see are:
>>
>> -latin1: Passphrase is a stream of octets, each of which is a single
>> unicode
>> character in the range 0-255.
>
> I would prefer to call it -binary or something like that... it
> On Jun 7, 2018, at 3:40 PM, Salz, Rich wrote:
>
> 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.
The flags I'd like to see are:
-latin1: Passphras
> On Jun 11, 2018, at 11:46 AM, Salz, Rich wrote:
>
> And the docs for this *new flag* explain that the behavior could change in
> the future.
There must be no "change in the future". Whatever flags
we add now, must implement a stable interface. A flag
that changes behaviour is useless.
-
> On Jun 7, 2018, at 3:59 PM, Salz, Rich wrote:
>
> 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 t
On Thu, Jun 07, 2018 at 09:01:15PM +0200, Richard Levitte wrote:
> 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 (for example, we - or well, *I* - know that VMS has the
> iconv API in the C RT
> On Jun 7, 2018, at 11:19 AM, Richard Levitte wrote:
>
> Regarding general use of other libraries, please think carefully before
> voting, 'cause this *is* tricky. If you have a look, you will see that we
> *currently* depend on certain standard libraries, such as, for example,
> libdl. An
> On Jun 6, 2018, at 12:52 PM, David Benjamin wrote:
>
> Oh, I didn't realize that document existed. Although it doesn't say that it
> is overriding the BMPString restrictions. It says it "does not add any
> further restrictions to the input passwords of these methods, however it is
> RECOM
https://tools.ietf.org/html/draft-mavrogiannopoulos-pkcs5-passwords-02#section-4
https://tools.ietf.org/html/draft-mavrogiannopoulos-pkcs5-passwords-02#section-5.2
> On Jun 6, 2018, at 11:23 AM, David Benjamin wrote:
>
> Is there a spec citation for this, or some documented experiments against
> On Jun 3, 2018, at 4:45 AM, Richard Levitte wrote:
>
> Yeah, I just learned that myself. Somehow, I thought wchar_t would be
> Unicode characters. So ok, with this information, UTF-8 makes
> sense...
Nico has convinced me that the mapping from UTF-8 to BMPString should
be UTF-16, which is
> On Jun 2, 2018, at 2:36 AM, Richard Levitte wrote:
>
>> Canonicalize when importing for use with the store API.
>
> Yup.
>
>> Not sure whether wchar_t though, just octet string in UTF-8 seems saner.
>
> Dunno about that, really. The aim, to quote David W, is to make it
> *hard* for appli
> On Jun 1, 2018, at 6:47 PM, Richard Levitte wrote:
>
> Ah, forgot one important detail: it is well understood that *all*
> file based objects will get the same requirements, right? That goes
> for anything protected through PKCS#5 as well (good ol' PEM
> encryption, PKCS#8 objects and what
> On Jun 1, 2018, at 6:16 PM, Richard Levitte wrote:
>
> (I'm currently looking into alternatives where a UI_METHOD can present
> several variants of the same pass phrase, thus making it possible for
> the application to virtually say "hey, try one of these" instead of
> "hey, try this one"...
> On Jun 1, 2018, at 5:51 PM, Kurt Roeckx wrote:
>
> That would then just mean that the apps need to do the correct
> thing and convert it to UTF-8.
Module legacy files, with a passphrase in some other encoding.
For those the applications will have to provide the right
non-UTF8 octet string,
> On Jun 1, 2018, at 5:26 PM, Salz, Rich wrote:
>
> So maybe I should just create a PR to update INSTALL with the Mac recipe?
I just use:
./Configure --prefix=/some/where [options] shared darwin64-x86_64-cc
--
Viktor.
___
openssl
> On May 24, 2018, at 4:42 PM, Richard Levitte wrote:
>
> Those are non-standard and a matter of personal taste. I used those before I
> discovered --fixup and --squash. How many variants should we support?
>
> (I'm not totally against the idea, mind you...)
Let's stick with the standard ve
https://travis-ci.org/openssl/openssl/jobs/382694134
https://api.travis-ci.org/v3/job/382694134/log.txt
Test Summary Report
---
../test/recipes/70-test_comp.t (Wstat: 26624 Tests: 0 Failed:
0)
Non-zero exit status: 104
Parse errors: No plan found in TAP outp
> On May 22, 2018, at 8:43 PM, Salz, Rich wrote:
>
> So do you guys use the ghmerge script or own procedures? I'm curious.
Good point, I've not yet had a chance to look at ghmerge and figure
out how/whether to use it. If that continues, ... my preferences for
its implementation don't carry m
> On May 22, 2018, at 8:37 PM, Salz, Rich wrote:
>
> No, I'm sure it does not. I think the safer thing is to do a full build, to
> catch things like make update errors, and such. I also run the test suite
> before I submit.
I do the same, but I am reluctant having a script doing it for me
> On May 21, 2018, at 8:15 AM, Salz, Rich wrote:
>
> The ghmerge script has a commented-out call to “opensslbuild” to build+test
> before submitting.
> I would like to enable that, and add either –build or –nobuild flags.
> Thoughts?
It probably does not know how/where I prefer to do builds
> On Apr 28, 2018, at 8:42 PM, Benjamin Kaduk wrote:
>
> [ ... nothing I don't agree with ... ]
We're on the same page here. OpenSSL the built-in defualt
callback can re-issue by default, so long as custom callbacks
can choose to not re-issue (their return code is honoured).
My other observa
> On Apr 28, 2018, at 2:41 PM, Kurt Roeckx wrote:
>
> So should I send that mail?
I made some editorial changes to the Wiki section on SNI.
No strong views on sending the mail...
--
Viktor.
___
openssl-project mailing list
openssl-project@
> On Apr 24, 2018, at 9:29 AM, Benjamin Kaduk wrote:
>
> To be clear, the current draft explicitly says "Servers SHOULD issue
> new tickets with every connection." This is not a MUST, but is
> perhaps strong enough guidance to merit overriding the existing
> ticket callback semantics.
Fine ad
> On Apr 22, 2018, at 9:49 PM, Viktor Dukhovni
> wrote:
>
> - Client-side diagnostics -
On the server side I see that even when the ticket callback returns "0" to
accept and not re-issue the ticket, a new ticket is requested anyway. I'd like
to be ab
> On Apr 23, 2018, at 3:35 AM, Matt Caswell wrote:
>
>> * With TLS 1.3 a new session is generated even sessions are
>>resumed, because the server responds with a new ticket
>>in the event of session resumption. With TLS 1.2 sessions
>>that had sufficient remaining lifetime did not
I tested a Postfix server and client built against OpenSSL 1.1.0,
using 1.1.1 run-time libraries. This exercised peer certificate
fingerprint matching and session resumption. No major issues.
The only interesting observations are:
* With TLS 1.3 a new session is generated even sessions are
> On Apr 22, 2018, at 12:16 PM, Richard Levitte wrote:
>
> openssl-users> > We are considering if we should enable TLS 1.3 by default or
> not,
> openssl-users> > or when it should be enabled. For that, we would like to
> know how
> openssl-users> > applications behave with the current versio
> On Apr 21, 2018, at 3:45 PM, Kurt Roeckx wrote:
>
>>> The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
>>> 1.3 brings a lot of changes that might cause incompatibility. For
>>> an overview see https://wiki.openssl.org/index.php/TLS1.3
>>
>> Should the Wiki mention the obser
> On Apr 21, 2018, at 2:42 PM, Kurt Roeckx wrote:
>
> Here is some attempt:
>
> The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> 1.3 brings a lot of changes that might cause incompatibility. For
> an overview see https://wiki.openssl.org/index.php/TLS1.3
Should the Wiki me
> On Apr 19, 2018, at 1:48 PM, Matt Caswell wrote:
>
>> I might suggest conditioning it on the compile-time version of OpenSSL
>> headers. This is a common transition strategy for systems working
>> through ABI constraints. (In some systems, this is implemented as some
>> target SDK version.)
>
> On Apr 19, 2018, at 4:24 PM, Salz, Rich wrote:
>
> Viktor found my comment offensive, which was not my intent. I was trying to
> be light-hearted in commenting on how Viktor dismissed all the issues David
> raised.
>
> If, in doing so, I went beyond our code of conduct and offended, I am
> On Apr 19, 2018, at 2:54 PM, Salz, Rich wrote:
>
> David has pointed out valid use-cases. I think most use-cases will "just
> work." We should document the known sharp edges.
I am pointing valid use-cases that David has not taken into account, and
conformance ratchets have cost/benefit t
1 - 100 of 142 matches
Mail list logo
