Re: [openssl-dev] Openssl 1.0.2 stable SNAP 20170309 issue

Already fixed. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Openssl 1.0.2 stable SNAP 20170309 issue

Script started on Thu Mar 9 05:45:36 2017 root@doctor:/usr/source/openssl-1.0.2-stable-SNAP-20170309 # make making all in crypto... making all in crypto/objects... making all in crypto/md4... making all in crypto/md5... making all in crypto/sha... making all in crypto/mdc2... making all in

Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

Hello. Richard Levitte wrote: |I've added a change with documentation: | |https://github.com/openssl/openssl/pull/2818 | |Please go in and comment, or if you don't have a github account, feel |free to comment here. Thank you, i have added it to my makefile 1:1. Ciao!

Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

Hello. Richard Levitte wrote: |In message <20170301221703.tfwpu%stef...@sdaoden.eu> on Wed, 01 Mar \ |2017 23:17:03 +0100, Steffen Nurpmeso said: | |steffen> Yes, i mean, i just didn't know this, it is not mentioned anywhere |steffen> (i think that

Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

In message <20170301221703.tfwpu%stef...@sdaoden.eu> on Wed, 01 Mar 2017 23:17:03 +0100, Steffen Nurpmeso said: steffen> Yes, i mean, i just didn't know this, it is not mentioned anywhere steffen> (i think that would well be worth in entry in INSTALL), and steffen> i really

Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

Hello, Richard Levitte wrote: |In message <20170301165032.8jhwg%stef...@sdaoden.eu> on Wed, 01 Mar \ |2017 17:50:32 +0100, Steffen Nurpmeso said: | |steffen> "Salz, Rich" wrote: |steffen> |> This is new behaviour, until now the

Re: [openssl-dev] [Bug] apps: -CApath does not fail for non-directories (on Linux)

Hello again, Viktor Dukhovni wrote: |> On Mar 1, 2017, at 11:46 AM, Steffen Nurpmeso wrote: |> No, not that i know. But this -- thanks -- lead me to the |> following, which is the KISS that you want? ... |> diff --git a/apps/apps.c

Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

Good evening. Viktor Dukhovni wrote: |> On Mar 1, 2017, at 11:13 AM, Steffen Nurpmeso wrote: |> |> $ ldd /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl |> ... |> libssl.so.1.1 => not found |> libcrypto.so.1.1 => not found |> |> This is

Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

In message <20170301165032.8jhwg%stef...@sdaoden.eu> on Wed, 01 Mar 2017 17:50:32 +0100, Steffen Nurpmeso said: steffen> "Salz, Rich" wrote: steffen> |> This is new behaviour, until now the installation was always self-contain\ steffen> |> ed steffen>

Re: [openssl-dev] [Bug] apps: -CApath does not fail for non-directories (on Linux)

> On Mar 1, 2017, at 11:46 AM, Steffen Nurpmeso wrote: > > No, not that i know. But this -- thanks -- lead me to the > following, which is the KISS that you want? > Ciao! > > diff --git a/apps/apps.c b/apps/apps.c > index 216bc797d..3afbbaef2 100644 > --- a/apps/apps.c >

Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

"Salz, Rich" wrote: |> This is new behaviour, until now the installation was always self-contain\ |> ed |> when configured via |> |> ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared | |Did you install the libraries in a standard place? | |> I think this should

Re: [openssl-dev] [Bug] apps: -CApath does not fail for non-directories (on Linux)

Sorry for the late reply, this really is a slow machine (and i cleanup again completely anything once it is installed, _and_ the tests compile a long time even if not run).. "Salz, Rich" wrote: |> I am sorry, but i have no github account. Maybe it is possible to \ |> have

Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

> This is new behaviour, until now the installation was always self-contained > when configured via > > ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared Did you install the libraries in a standard place? > I think this should at least be noted in CHANGES or so. I don't think so. I

[openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

Oh, hello again, now i finally have updated (without "make tests?") and it seems i now have to fill in $LD_LIBRARY_PATH to get running: $ ldd /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl ... libssl.so.1.1 => not found libcrypto.so.1.1 => not found This is new behaviour, until now the

Re: [openssl-dev] [Bug] apps: -CApath does not fail for non-directories (on Linux)

> I am sorry, but i have no github account. Maybe it is possible to have some > @bug address which creates issues automatically? Nah, too much spam will happen :( Posting to openssl-dev is fine. > ? openssl version > OpenSSL 1.0.2k 26 Jan 2017 > ?

[openssl-dev] [Bug] apps: -CApath does not fail for non-directories (on Linux)

Hello. I am sorry, but i have no github account. Maybe it is possible to have some @bug address which creates issues automatically? I see this on ? openssl version OpenSSL 1.0.2k 26 Jan 2017 ? /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl version

Re: [openssl-dev] Participate in Code Health Tuesday (tomorrow, Feb 28th)

This is happening NOW :) https://github.com/openssl/openssl/pulls?q=is%3Apr%20label%3Acode-health On Mon, Feb 27, 2017 at 4:24 PM Richard Levitte wrote: > I'd suggest prefixing the PR subject with "code-health:" or > "[code-health]", just like work in progress is prefixed

Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

On 02/26/2017 02:10 AM, Richard Levitte wrote: > In message on Fri, 27 Jan > 2017 10:54:35 -0600, Benjamin Kaduk via openssl-dev > said: > > openssl-dev> There was some discussion about 1.0.1 being EoL on a FreeBSD >

Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

On 02/26/2017 07:26 AM, Kurt Roeckx wrote: > It's normal that you might see some symbols removed if you compare > something like 1.0.1t against 1.0.2, but it shouldn't when compared > to 1.0.2k. I agree, and figured this out at some point after I sent the initial query. Given the low interest

[openssl-dev] Private key size in req output

Hello, Currently the req command prints key size before generating the private key. If the key size can't be determined from the specified parameters, it prints the default value. For some algorithms (e.g GOST ones) the key bits value is fixed and can't be extracted from the parameters. In such

Re: [openssl-dev] Participate in Code Health Tuesday (tomorrow, Feb 28th)

I'd suggest prefixing the PR subject with "code-health:" or "[code-health]", just like work in progress is prefixed "WIP:" or "[WIP]" Cheers, Richard In message <9ecbf19a-3239-440c-b874-b959b6bb9...@akamai.com> on Mon, 27 Feb 2017 14:54:09 +, "Short, Todd" said: tshort>

Re: [openssl-dev] Participate in Code Health Tuesday (tomorrow, Feb 28th)

Ah... Well, just add "Code Health" to your PR title, and we'll do the labeling. On Mon, Feb 27, 2017 at 3:54 PM Short, Todd wrote: > I’m not sure us mere mortals can add a label to a PR... > -- > -Todd Short > // tsh...@akamai.com > // "One if by land, two if by sea, three if

Re: [openssl-dev] Participate in Code Health Tuesday (tomorrow, Feb 28th)

I’m not sure us mere mortals can add a label to a PR... -- -Todd Short // tsh...@akamai.com // "One if by land, two if by sea, three if by the Internet." On Feb 27, 2017, at 5:04 AM, Emilia Käsper > wrote: Hi OpenSSL

[openssl-dev] Participate in Code Health Tuesday (tomorrow, Feb 28th)

Hi OpenSSL developers! We’re always looking for ways to improve code quality and pay our technical debt. This week we thought we’d run a little experiment. We declare this Tuesday (Feb 28th) Code Health Tuesday. We’ll be setting some time aside to do cleanups in the codebase. The theme is

Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

26.02.2017, 16:27, "Kurt Roeckx":> On Sun, Feb 26, 2017 at 09:26:06AM +0300, Andrey Ponomarenko wrote:>>  31.01.2017, 10:21, "Nikos Mavrogiannopoulos":>>  > On Fri, 2017-01-27 at 10:54 -0600, Benjamin Kaduk via openssl-dev>>  > wrote:>>  >>  [moving from github to -dev]>>    >>  On 01/27/2017

Re: [openssl-dev] Travis [extended tests] tag

>> In order to improve CI turn-around times Travis config in master branch >> was tweaked to minimize the time it takes to process pull requests. This >> is done by "short-circuiting" most expensive tests: sanitizers, >> coverage, wine-based tests. Thing to keep in mind is that >>

Re: [openssl-dev] Travis [extended tests] tag

> > tests was arranged by adding "[extended tests]" tag to *last* commit. ... > > And in the context it's worth keeping in mind that it's possible to > > skip CI tests altogether by tagging commit with "[skip ci]". This ... >> > Can you explain how to tag it? Your commit message should have the

Re: [openssl-dev] Travis [extended tests] tag

On Sun, Feb 26, 2017 at 11:23:42PM +0100, Andy Polyakov wrote: > In order to improve CI turn-around times Travis config in master branch > was tweaked to minimize the time it takes to process pull requests. This > is done by "short-circuiting" most expensive tests: sanitizers, > coverage,

[openssl-dev] Travis [extended tests] tag

In order to improve CI turn-around times Travis config in master branch was tweaked to minimize the time it takes to process pull requests. This is done by "short-circuiting" most expensive tests: sanitizers, coverage, wine-based tests. Thing to keep in mind is that "short-circuited" test come out

Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

On Sun, Feb 26, 2017 at 09:26:06AM +0300, Andrey Ponomarenko wrote: > 31.01.2017, 10:21, "Nikos Mavrogiannopoulos": > > On Fri, 2017-01-27 at 10:54 -0600, Benjamin Kaduk via openssl-dev > > wrote: > >>  [moving from github to -dev] > >> > >>  On 01/27/2017 07:36 AM, mattcaswell wrote: > >>  >

Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

In message on Fri, 27 Jan 2017 10:54:35 -0600, Benjamin Kaduk via openssl-dev said: openssl-dev> There was some discussion about 1.0.1 being EoL on a FreeBSD list [0], openssl-dev> and whether it would make sense to

Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

31.01.2017, 10:21, "Nikos Mavrogiannopoulos": > On Fri, 2017-01-27 at 10:54 -0600, Benjamin Kaduk via openssl-dev > wrote: >>  [moving from github to -dev] >> >>  On 01/27/2017 07:36 AM, mattcaswell wrote: >>  > 1.0.2 is the software version. >>  > The numbers on the end of lbssl.so.1.0.0 refer to

[openssl-dev] Feature discussion - Zero-knowledge-proofs

I know, I know, zero knowledge proofs are not crypto. But: We live in the post-snowden era. Providers and centralized hosting services are becomming a larger threat than man-in-the-middle attacks. People (including me) are loosing their trust in cryptography that's only meant to protect sensitive

Re: [openssl-dev] Openssl 1.0.2 snapshot bug

Fixed now. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Openssl 1.0.2 snapshot bug

Yup, we have a fix coming up: https://github.com/openssl/openssl/pull/2713 In message <20170223125425.ga77...@doctor.nl2k.ab.ca> on Thu, 23 Feb 2017 05:54:25 -0700, The Doctor said: doctor> doctor> Script started on Thu Feb 23 05:41:55 2017 doctor> You have mail.

Re: [openssl-dev] Integrate EVP Cipher into OpenSSL cli Speed Test

Look at some of the changes to pull in Poly1305 and SipHash in to EVP: https://github.com/openssl/openssl/commit/52ad5b60e3a1fef12a1a5ea01527a90b8f92a34b https://github.com/openssl/openssl/commit/3f5616d734a92fdf99ab827f21e5b6cab85e7194 -- -Todd Short //

Re: [openssl-dev] Openssl 1.0.2 snapshot bug

On 23/02/17 12:54, The Doctor wrote: > Please fix! > This fix is already on the way: https://github.com/openssl/openssl/pull/2713 Matt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Openssl 1.0.2 snapshot bug

Script started on Thu Feb 23 05:41:55 2017 You have mail. root@doctor:/usr/source/openssl-1.0.2-stable-SNAP-20170223 # makeless /usr/contrib/b in/configopenssl [?1h= #!/usr/local/bin/bash CC=/usr/local/bin/clang39 ./Configure --prefix=/usr/ BSD-x86_64 fips enable-gmp 

[openssl-dev] Integrate EVP Cipher into OpenSSL cli Speed Test

Hello, I successfully managed to integrate an encryption cipher into the EVP and has been tested to work and now I'd like to get some speed tests of the cipher using openssl's integrated speed test via the command line with the "-evp" flag. What I've done so far to try and integrate it

[openssl-dev] ABI Navigator for OpenSSL

Hello, I'd like to present a new project called "ABI Navigator" for searching binary symbols (functions, global data, etc.) in OpenSSL and other open-source libraries: https://abi-laboratory.pro/index.php?view=navigator The project allows to find out in which versions of the library some

[openssl-dev] STORE, the continued story

Hi, last time I talked about the STORE effort, it was about search for specific data. I believe that this PR covers quite a lot of what is desired, and is designed to be easily extensible: https://github.com/openssl/openssl/pull/2688 (it's built on top of PRs #2011 and #1961, making it look

[openssl-dev] Problem with Commit 3fd181a8b5b85a1f7383e82438da494a08f7d843, Remove an option related to a deprecated flag.

This commit removes the cms and smime "-nooldmime" option on the grounds that the flags they use "CMS_NOOLDMIMETYPE" and "PKCS7_NOOLDMIMETYPE" are not used in the pkcs7/cms code. But those flags *are* used. In include/openssl/pkcs7.h we have: # define PKCS7_NOOLDMIMETYPE 0x400 And in

Re: [openssl-dev] OpenSSL version 1.1.0e published

FYI, and because i don't have a github account, though this could be related to ticket #1635, on a x86_64 GNU LibC based Linux via openssl: cd openssl.git &&\ if [ -f NULL ]; then git checkout `cat NULL`; fi &&\ ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw

[openssl-dev] OpenSSL Security Advisory

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [16 Feb 2017] Encrypt-Then-Mac renegotiation crash (CVE-2017-3733) Severity: High During a renegotiation handshake if the

[openssl-dev] OpenSSL version 1.1.0e published

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 1.1.0e released === OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.0e of our open

[openssl-dev] OpenSSL Project Bylaws

I am pleased to be able to announce the publication of our new Project Bylaws. I have written a short blog post about what we are hoping to achieve and some of the thinking that went into these here: https://www.openssl.org/blog/blog/2017/02/13/bylaws/ The bylaws themselves are available here:

Re: [openssl-dev] Possible wrong restore register order in SEH for ecp_nistz256

>> Does this fix it? >>https://github.com/openssl/openssl/pull/2582 > > It's unrelated issues. Yes, it's typo in full_handler, will be fixed > [tomorrow]... Fix has been applied. Thank you for report! -- openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] SNI by default in s_client

> On Feb 13, 2017, at 12:32 PM, Viktor Dukhovni > wrote: > > That said, I don't think that enabling SNI by default *in s_client* is > sufficient cause to motivate such a feature. The s_client command adds > new options from time to time, and IIRC we've never before

Re: [openssl-dev] SNI by default in s_client

> On Feb 13, 2017, at 12:35 PM, Salz, Rich wrote: > > I think it should be called out in the docs and CHANGES however. Yes, definitely. -- Viktor. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] SNI by default in s_client

Having asked for Viktor's opinion, and reading it, I withdraw my concerns about changing the behavior and adding the flag. I think it should be called out in the docs and CHANGES however. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] SNI by default in s_client

On 02/13/2017 10:13 AM, Matt Caswell wrote: > I was targeting this change for 1.1.1. The issue is that this does > change command line behaviour between minor versions of the 1.1.x series > - which is supposed to preserve API and ABI compatibility. Of course > this change affects neither API or

Re: [openssl-dev] SNI by default in s_client

On 13/02/17 16:55, Salz, Rich wrote: >> extension by default that wasn't there before - and that we've already >> decided to add new extensions in 1.1.1 due to the forthcoming >> TLSv1.3 support. > > You mean adding new extensions in the wire protocol? Or are did we modify > any API/ABI

Re: [openssl-dev] SNI by default in s_client

> On Feb 13, 2017, at 11:13 AM, Matt Caswell wrote: > > I'd like to canvas opinion on this PR: > https://github.com/openssl/openssl/pull/2614 > > At the moment s_client does not add the SNI extension by default. You > have to explicitly ask for it using the "-servername"

Re: [openssl-dev] SNI by default in s_client

> extension by default that wasn't there before - and that we've already > decided to add new extensions in 1.1.1 due to the forthcoming > TLSv1.3 support. You mean adding new extensions in the wire protocol? Or are did we modify any API/ABI behavior? > On the other hand you could argue that

Re: [openssl-dev] SNI by default in s_client

On Mon, 2017-02-13 at 16:13 +, Matt Caswell wrote: > I'd like to canvas opinion on this PR: > https://github.com/openssl/openssl/pull/2614 > The PR above changes the default behaviour of s_client so that it > always > sends SNI, and adds a "-noservername" option to suppress sending it >

[openssl-dev] SNI by default in s_client

I'd like to canvas opinion on this PR: https://github.com/openssl/openssl/pull/2614 At the moment s_client does not add the SNI extension by default. You have to explicitly ask for it using the "-servername" option. This can lead to some problems where servers reject connection attempts from

[openssl-dev] Forthcoming OpenSSL release

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Forthcoming OpenSSL release === The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.0e This release will be made available on 16th February 2017 between 1200-1600 UTC, and will

Re: [openssl-dev] Possible wrong restore register order in SEH for ecp_nistz256

> Does this fix it? >https://github.com/openssl/openssl/pull/2582 It's unrelated issues. Yes, it's typo in full_handler, will be fixed [tomorrow]... -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Possible wrong restore register order in SEH for ecp_nistz256

Does this fix it? https://github.com/openssl/openssl/pull/2582 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Possible wrong restore register order in SEH for ecp_nistz256

Hi, I noticed Windows exception handler is added to ecp_nistz256-x86_64.pl. In function full_handler, when restore register contents, rbx is the first one with the smallest offset: 3181 mov -8(%rax),%rbx 3182 mov -16(%rax),%rbp but when do push, rbp is always the

Re: [openssl-dev] (future) STORE vs X509_LOOKUP_METHOD by_dir

In message <589b86c1.10...@roumenpetrov.info> on Wed, 08 Feb 2017 22:59:45 +0200, Roumen Petrov said: openssl> Hi Richard, openssl> openssl> Richard Levitte wrote: openssl> > Hi, openssl> > openssl> > I've some ponderings that I need to bounce a bit with you all.

Re: [openssl-dev] (future) STORE vs X509_LOOKUP_METHOD by_dir

Hi Richard, Richard Levitte wrote: Hi, I've some ponderings that I need to bounce a bit with you all. Some have talked about replace the X509_LOOKUP_METHOD X.509 lookup method could return certificate , revocation list or EVP_KEY (structure x509_object_st). Unfortunately functionality of

[openssl-dev] PR 2351: Place ticket keys into secure memory

vdukhovi wrote: I don't think this change is useful at present. Most applications run with a single context for the lifetime of the process, so this makes no difference. We (perhaps I) first need to implement automated key rotation, and only then do I think it make sense to worry about

[openssl-dev] Doubt regarding process of invalid [D]TLS record

Hi All, In dtls1_get_record(), we are calling ssl3_read_n to get 13 bytes of DTLS record header from socket and then based on the length in record header, we again call ssl3_read_n to get record payload from socket. Here we are handling invalid record, like length less 13 bytes or invalid

[openssl-dev] Internationalized Email Addresses in X.509 certificates

Here is a patch designed for the support of the https://tools.ietf.org/html/ draft-ietf-lamps-eai-addresses-06 draft which is in the last call phase of the Lamps WG. The patch https://github.com/openssl/openssl/pull/2560 implements the support of the SmtpUtf8 OTHERNAME value. Current problems

Re: [openssl-dev] Bug reports and patches for OpenSSL

Thank you for pointing out. That is not what I expect, but very important point for fix. Sincerely, Yuchi Tian On Mon, Feb 6, 2017 at 4:59 PM, Lars Nordin wrote: > On 2017-02-05 07:54, yuchi tian wrote: > > Dear OpenSSL developers, > > We are software engineering

Re: [openssl-dev] Bug reports and patches for OpenSSL

On 2017-02-05 07:54, yuchi tian wrote: Dear OpenSSL developers, We are software engineering researchers at University of Virginia. As part of a research project, we have built a tool for automatically finding and fixing error handling bugs and are testing it on various cryptographic

Re: [openssl-dev] (future) STORE vs X509_LOOKUP_METHOD by_dir

On Sun, 2017-02-05 at 16:47 +0100, Richard Levitte wrote: > Hi, > > I've some ponderings that I need to bounce a bit with you all. > > Some have talked about replace the X509_LOOKUP_METHOD bit with the > STORE module I'm building, and while STORE isn't ready for it yet, I > have some thoughts on

Re: [openssl-dev] Bug reports and patches for OpenSSL

> Guidance for how to correctly submit patches is given in the > CONTRIBUTING file here: > https://github.com/openssl/openssl/blob/master/CONTRIBUTING > Please could you submit your fixes as a github pull request? One pull > request for all of these issues should be fine. Thank you for the

Re: [openssl-dev] Bug reports and patches for OpenSSL

> Will you make the tool and the corresponding scientific publication > public? Yes. We are currently in the step of evaluating our tools. We will submit our work and share our tools when the project is done. Sincerely, Yuchi Tian On Sun, Feb 5, 2017 at 6:16 AM, Hanno Böck

[openssl-dev] (future) STORE vs X509_LOOKUP_METHOD by_dir

Hi, I've some ponderings that I need to bounce a bit with you all. Some have talked about replace the X509_LOOKUP_METHOD bit with the STORE module I'm building, and while STORE isn't ready for it yet, I have some thoughts on how the two can approach each other. This would involve one or two

Re: [openssl-dev] Bug reports and patches for OpenSSL

On 05/02/17 06:54, yuchi tian wrote: > Dear OpenSSL developers, > > We are software engineering researchers at University of Virginia. As > part of a research project, we have built a tool for automatically > finding and fixing error handling bugs and are testing it on > various cryptographic

Re: [openssl-dev] Bug reports and patches for OpenSSL

On Sun, 5 Feb 2017 01:54:06 -0500 yuchi tian wrote: > We are software engineering researchers at University of Virginia. As > part of a research project, we have built a tool for automatically > finding and fixing error handling bugs and are testing it on > various

[openssl-dev] Bug reports and patches for OpenSSL

Dear OpenSSL developers, We are software engineering researchers at University of Virginia. As part of a research project, we have built a tool for automatically finding and fixing error handling bugs and are testing it on various cryptographic libraries and applications that use them. In the

Re: [openssl-dev] [openssl.org #4681] Resolved: X.509 load method

> Resolved? > Hmm, how to implement X.509 lookup method with 1.1+ API? It wasn't really resolved, it was moved to GH issue 2531. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4681] Resolved: X.509 load method

Rich Salz via RT wrote: According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. Resolved? Hmm, how to implement X.509 lookup method with 1.1+ API? Regards, Roumen Petrov -- openssl-dev mailing list To

[openssl-dev] Heads up -- RT tickets moving to GH issues

Just to let you know, we found a tool to migrate RT to GitHub issues and will be doing that shortly. This will just about double the number of open issues we have and, unfortunately, push the existing (active ones) down a few pages. -- openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

On Fri, 2017-01-27 at 10:54 -0600, Benjamin Kaduk via openssl-dev wrote: > [moving from github to -dev] > > On 01/27/2017 07:36 AM, mattcaswell wrote: > > 1.0.2 is the software version. > > The numbers on the end of lbssl.so.1.0.0 refer to the ABI version - > > which is different. Software

Re: [openssl-dev] SSL_set_bio(ssl, bio, bio) and BIO_up_ref(bio)

Ah, right, so indeed I did misunderstand. So if I use SSL_set_bio without calling BIO_free myself, the refcount works out automatically and I don't need to up myself. That indeed works, and explains why the s_server and other places don't suffer from this. In that case, I would say that for having

Re: [openssl-dev] SSL_set_bio(ssl, bio, bio) and BIO_up_ref(bio)

On 30/01/17 17:19, Mischa Salle wrote: > Hi Matt, > > thanks for the quick and extensive answer! > > I've tried by replacing all SSL_set_bio(ssl, bio, bio) with a separate > SSL_set0_rbio(ssl, bio) and SSL_set0_wbio(ssl, bio). > I've also removed all BIO_free statements and if I understand you

Re: [openssl-dev] SSL_set_bio(ssl, bio, bio) and BIO_up_ref(bio)

Hi Matt, thanks for the quick and extensive answer! I've tried by replacing all SSL_set_bio(ssl, bio, bio) with a separate SSL_set0_rbio(ssl, bio) and SSL_set0_wbio(ssl, bio). I've also removed all BIO_free statements and if I understand you correctly, I should then *not* need to call

Re: [openssl-dev] SSL_set_bio(ssl, bio, bio) and BIO_up_ref(bio)

On 30/01/17 10:13, Mischa Salle wrote: > Hi all, > > I noticed a doublefree when calling SSL_set_bio(ssl, bio, bio) followed > by either SSL_set_bio(ssl, NULL, NULL) or SSL_set_io_SSL_free(ssl). > Valgrind shows the double free, and I see the assert in >

[openssl-dev] SSL_set_bio(ssl, bio, bio) and BIO_up_ref(bio)

Hi all, I noticed a doublefree when calling SSL_set_bio(ssl, bio, bio) followed by either SSL_set_bio(ssl, NULL, NULL) or SSL_set_io_SSL_free(ssl). Valgrind shows the double free, and I see the assert in https://github.com/openssl/openssl/blob/master/crypto/bio/bio_lib.c#L122 fail. This is all

Re: [openssl-dev] MD5 speed

> I had some surprising results of the speed command when testing the > md5 speed on the 1.1.0-stable branch (for both a shared and a static > build): > openssl speed md5 returns: > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes > 16384 bytes > md5

Re: [openssl-dev] MD5 speed

On Sun, Jan 29, 2017 at 10:53 PM, Peter Waltenberg wrote: > > No one cares ?. I was rather thinking the same thing. Pretty much the same deprecated status for SHA1, too. Want to talk about poly1305? - M -- openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] MD5 speed

No one cares ?.I'd suggest you check for alignment issues first as that tends to dominate at small block sizes.The no one cares is only partly in jest as MD5 is dead, but not yet buried. And in the grand scheme of things even a 2:1 performance hit on 16 byte blocks is unlikely to change the

[openssl-dev] MD5 speed

I had some surprising results of the speed command when testing the md5 speed on the 1.1.0-stable branch (for both a shared and a static build): openssl speed md5 returns: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes md5 115869.46k

Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

I guess the dashboard is only picking up incremental differences, then, so the four missing symbols is just for 1.0.1u to 1.0.2 (no letter); any symbols that were added to both 1.0.1 and 1.0.2 letter releases (e.g., for CVE fixes) would show up as "removed" since they weren't in the initial 1.0.2

Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

Hi, SRP_VBASE_get1_by_user() was ADDED to 1.0.2g 1 march 2016 [CVE-2016-0798]. I remember it very well ! ;-) Michel -Message d'origine- De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Salz, Rich via openssl-dev Envoyé : vendredi 27 janvier 2017 19:49 À : Kaduk,

Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

The tool looks good, but either you didn't find the right link, or it's got bugs. Of the four symbols you found, ASN1_STRING_clear_free(), SRP_user_pwd_free(), and SRP_VBASE_get1_by_user() all exist; only ENGINE_load_rsax() was removed. -- Senior Architect, Akamai Technologies Member,

Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

On 27/01/17 16:54, Benjamin Kaduk via openssl-dev wrote: > [moving from github to -dev] > > On 01/27/2017 07:36 AM, mattcaswell wrote: >> >> 1.0.2 is the software version. >> The numbers on the end of lbssl.so.1.0.0 refer to the ABI version - >> which is different. Software version 1.0.2 is a

Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

[moving from github to -dev] On 01/27/2017 07:36 AM, mattcaswell wrote: > > 1.0.2 is the software version. > The numbers on the end of lbssl.so.1.0.0 refer to the ABI version - > which is different. Software version 1.0.2 is a drop in replacement > for 1.0.1, which is a drop in replacement for

Re: [openssl-dev] Netscape Comment Tag Value

OpenSSL is correct to expect the extension as an IA5STRING. The netscape-comment extension is defined with the OID 2.16.840.1.113730.1.13 and should be an IA5STRING. Some references (It's not in any RFC afaik): https://docs.oracle.com/cd/E19957-01/816-5533-10/ext.htm#1043093

[openssl-dev] Netscape Comment Tag Value

Hi, I have an OpenSSL based client which fails when validating a certificate generated by IBM RACF. It fails because the ASN.1 tag for the X509v3 extension Netscape Comment is 19 (V_ASN1_PRINTABLESTRING) and OpenSSL is expecting 22 (V_ASN1_IA5STRING). Is this a bug in OpenSSL or RACF? Can

[openssl-dev] OpenSSL Security Advisory

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [26 Jan 2017] Truncated packet could crash via OOB read (CVE-2017-3731) = Severity: Moderate If an SSL/TLS server or

[openssl-dev] [openssl-announce] Akamai sponsors TLS 1.3

Many companies use OpenSSL, relatively few of them support it. I'm pleased to announce that Akamai (https://www.akamai.com/) has expanded its already substantial presence in the latter category. Akamai has contractually committed to funding implementation of TLS 1.3 in OpenSSL. That is something

[openssl-dev] OpenSSL version 1.1.0d published

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 1.1.0d released === OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.0d of our open

[openssl-dev] OpenSSL version 1.0.2k published

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 1.0.2k released === OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2k of our open

[openssl-dev] [openssl-announce] Forthcoming OpenSSL releases

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Forthcoming OpenSSL releases The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2k, 1.1.0d. These releases will be made available on 26th January 2017 between approximately

[openssl-dev] Fwd: [openssl-announce] Forthcoming OpenSSL releases

In case anyone on these lists missed this on the openssl-announce list: Forwarded Message Subject: [openssl-announce] Forthcoming OpenSSL releases Date: Mon, 23 Jan 2017 21:08:50 + (GMT) From: OpenSSL Reply-To: openssl-us...@openssl.org To:

<    4   5   6   7   8   9   10   11   12   13   >