On Mon, Feb 05, 2018 at 12:08:38PM +0530, Atul Gupta wrote:
> The objective of this patch is to add AEAD cipher aes-gcm
> to afalg. Portion of code is borrowed from e_aes.c. The AEAD
> auth size is set to program the TAG length. AAD (additional
> authenc data) is sent in iov along with data[in].
P
On Thu, Jan 18, 2018 at 05:34:05PM +0100, Patrick Steuer wrote:
>
> Though aead is in some sense more than a cipher mode of operation. Providing
> a dedicated api would have some advantages but i see that maybe i reopen a
> discussion:
>
> "We are also evaluating the following new features. -New
On Fri, Dec 22, 2017 at 09:30:19AM -0500, Ken Goldman wrote:
> On 12/22/2017 9:24 AM, Salz, Rich via openssl-users wrote:
> > > if (ptr!= NULL) free(ptr);
> > That shouldn’t be necessary for OpenSSL. If you find places where it is,
> > please open an issue.
>
> OK. I'll mention a few, but it'
On Fri, Dec 22, 2017 at 01:06:20PM +, Salz, Rich via openssl-dev wrote:
> Our intent is that all FREE functions can handle NULL. If you find things
> missing or undocumented, please open an issue on GitHub. Thanks!
I think we fixed all such cases in 1.1.0, all *_free() functions
should hand
On Mon, Nov 27, 2017 at 07:56:00PM +0300, Dmitry Belyavsky wrote:
> Here is the link to the draft:
> https://datatracker.ietf.org/doc/draft-belyavskiy-certificate-limitation-policy/
I'm wondering how you think that policy will be distributed and
why it needs signed. I expect that there will always
On Wed, Oct 25, 2017 at 05:19:23PM +0200, Tomas Mraz wrote:
>
> The problem is that by default the applications do not read the file and
> do not apply the defaults. Even the openssl s_client/s_server does not
> seem to work, but I might be doing something wrong.
>
> What I would like to see is a
On Tue, Sep 26, 2017 at 07:32:06AM +0200, Richard Levitte wrote:
>
> You mean to have nginx use the shared OpenSSL libraries, which also
> enables dynamic engines? Yes, that's the usual way to go about these
> things.
Do we support dynamic engines with a static build?
Kurt
--
openssl-dev mai
On Sun, Sep 17, 2017 at 08:04:10AM +0100, Matt Caswell wrote:
> On Sat, 16 Sep 2017 22:26:10 +0100
> Howard Chu via openssl-dev wrote:
>
> > In OpenSSL 1.1 on Linux (at least) libcrypto now has a dependency on
> > libpthread but this is not reflected in the pkgconfig file. As a result,
> > tool
On Tue, Aug 29, 2017 at 08:44:11PM +, Salz, Rich via openssl-dev wrote:
> Sure I can. Because the DRBG seeds from the system anyway
You can't assume that will work for all users.
Kurt
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On Tue, Aug 29, 2017 at 08:38:09PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> > If, based on its value, OpenSSL may decide that it now got “enough” entropy
> > and doesn’t need to
> > pull more from other sources before serving randomness to requestors – then
> > it is harmful.
> > “Over-conf
On Tue, Aug 29, 2017 at 06:50:37PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> On 8/29/17, 12:45, "openssl-dev on behalf of Salz, Rich via openssl-dev"
> wrote:
>
> ➢ An other problem with the current implemenation is that the
> ➢ randomness parameter that's now given to RAND_add() is
On Tue, Aug 29, 2017 at 01:05:21PM +, Dr. Matthias St. Pierre wrote:
>
> Currently it's only possible to customize the callbacks but not the
> deterministic algorithm. IMHO this is sufficient for the needs of a standard
> OpenSSL user who only wants control over the entropy source. A true ne
On Tue, Aug 29, 2017 at 11:31:03AM +, Dr. Matthias St. Pierre wrote:
> > -Ursprüngliche Nachricht-
> > Von: openssl-dev [mailto:openssl-dev-boun...@openssl.org] Im Auftrag von
> > Matt Caswell
> > Gesendet: Dienstag, 29. August 2017 12:17
> > An: openssl-dev@openssl.org
> > Betreff: Re
I actually plan to work on most of not all the things you mention.
This will probably result in the API changing before it's made
public. I'm probably slow, so please be patient.
Kurt
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On Thu, Aug 24, 2017 at 05:47:55PM +, Salz, Rich via openssl-dev wrote:
>
> >This is why I want to add things like that by default in the
> >additional data.
>
> On reseed or generate?
Mostly on generate, but I see little point in not doing it on
reseed.
Kurt
--
openssl-dev mai
On Thu, Aug 24, 2017 at 05:32:15PM +, Salz, Rich via openssl-dev wrote:
>
> >An idea that I had was to default to reseed on fork if we know we
> >have a working syscall.
... to get entropy
>
> Or /dev device too?
The point is that you can't be sure that /dev is still going to be
On Thu, Aug 24, 2017 at 08:07:54AM +1000, Peter Waltenberg wrote:
> The bad case I'm aware of is the fork() one as it's critical that the RNG
> state diverge on fork(). Without that you can get some very nasty
> behaviour in things like TLS servers. Some of which have a thread pool +
> fork() mo
On Wed, Aug 23, 2017 at 05:12:56PM -0400, Paul Kehrer wrote:
> On August 19, 2017 at 2:48:19 AM, Salz, Rich via openssl-dev (
> openssl-dev@openssl.org) wrote:
>
>
> I think the safest thing is for us to not change the default. Programs that
> know they are going to fork can do the right/safe thi
On Mon, Aug 21, 2017 at 06:12:16PM +0200, Kurt Roeckx wrote:
> So I guess you want an interface that can both add things to the
> "entropy" pool, and to the "additional data" pool? It shouldn't
> be that hard, I'll try to come up with some proposal soon.
On Mon, Aug 21, 2017 at 03:56:29PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> >> P.S. I wonder if it's feasible to have a configuration parameter that
> >> would allow me to tell the TLS code to invoke RAND_add_ex() before
> >> generating session keys?
> >
> > Either you accept that N
On Fri, Aug 18, 2017 at 09:22:48AM +0200, Tomas Mraz wrote:
> On Thu, 2017-08-17 at 22:11 +0200, Kurt Roeckx wrote:
> > On Thu, Aug 17, 2017 at 02:34:49PM +0200, Tomas Mraz wrote:
> > > On Thu, 2017-08-17 at 12:22 +, Salz, Rich via openssl-dev
> > > wrote:
>
On Thu, Aug 17, 2017 at 02:34:49PM +0200, Tomas Mraz wrote:
> On Thu, 2017-08-17 at 12:22 +, Salz, Rich via openssl-dev wrote:
> > I understand the concern. The issue I am wrestling with is strict
> > compatibility with the existing code. Does anyone really *want* the
> > RNG’s to not reseed
On Sun, Jul 09, 2017 at 09:15:32AM +0200, Richard Levitte wrote:
> In message
> on Sat,
> 8 Jul 2017 23:22:28 -0400, Matthew Stickney said:
>
> mtstickney> Back in 2010, there was some discussion on this list of adding
> code to
> mtstickney> load certificates from the system cert store on Wi
On Tue, Jul 04, 2017 at 05:42:42PM +0200, Richard Levitte wrote:
> In message
> <2f548b68de1c47dfaa6a3b0107080...@usma1ex-dag1mb1.msg.corp.akamai.com> on
> Tue, 4 Jul 2017 15:05:06 +, "Salz, Rich via openssl-dev"
> said:
>
> openssl-dev> > beldmit> What is the minimal version of the compil
On Wed, Jun 28, 2017 at 12:01:29PM -0500, Benjamin Kaduk via openssl-dev wrote:
>
> I'm not sure what you mean by "draining the kernel's entropy pools".
> That is, if you are adhering to the belief that taking random bits out
> of a generator removes entropy from it that must be replenished, does
On Tue, Jun 27, 2017 at 11:56:04AM -0700, John Denker via openssl-dev wrote:
> On 06/27/2017 02:28 AM, Matt Caswell wrote:
> >>
> >> I also agree that, by default, using the OS provided source makes a lot
> >> of sense.
>
> Reality is more complicated than that; see below.
>
> On 06/27/2017 11:5
On Tue, Jun 27, 2017 at 02:42:52PM +0200, Matthias St. Pierre wrote:
>
> So I have two questions:
>
> - Do you intend to continue supporting RAND_set_rand_method() or will there
> only be one 'perfect' random generator and no choice anymore?
I think we should have a default one, but an option t
On Mon, Jun 26, 2017 at 09:39:47PM -0700, John Denker via openssl-dev wrote:
>
> I'm not mentioning any names, but some people are *unduly*
> worried about recovery following compromise of the PRNG
> internal state, so they constantly re-seed the PRNG, to
> the point where it becomes a denial-of-s
On Mon, Jun 26, 2017 at 01:18:58PM -0700, John Denker via openssl-dev wrote:
> On 06/26/2017 12:41 PM, Salz, Rich wrote:
>
> > Suppose the chip supports RDRAND but the runtime doesn't have
> > getrandom or /dev/random?
>
> That's an easy one!
>
> Check the feature-test bit and then call RDRAND y
On Mon, Jun 26, 2017 at 11:29:19AM -0700, John Denker via openssl-dev wrote:
> What's your threat model? I know that sounds like a cliché,
> but it's actually important.
>
> In particular, in my world the #1 threat against any PRNG
> is improper seeding.
> -- If you trust the ambient OS to pro
On Mon, Jun 26, 2017 at 04:17:41PM +, Salz, Rich via openssl-dev wrote:
>
> > > Is it worth reposting my thoughts with your suggested wording changes?
> >
> > OK. Off-list or on. This stuff is important.
>
> Reposting.
>
> My thoughts.
>
> Randomness should be whitened. Anything feed i
On Mon, Jun 26, 2017 at 08:58:21AM -0700, John Denker via openssl-dev wrote:
> In the context of:
>
> >> If you mean for something to be hard for the attacker to guess,
> >> the word "adamance" can be used.
>
> On 06/26/2017 08:32 AM, Salz, Rich wrote:
>
> > All my attempts to look up a definiti
On Mon, Jun 26, 2017 at 07:30:52AM -0700, John Denker via openssl-dev wrote:
> On 06/26/2017 05:49 AM, Salz, Rich wrote:
>
> > Please take a look at GitHub pull request
>
> Is the RNG topic going to be discussed on github, or on openssl-dev?
> What about other topics?
>
> Having some topics one
On Thu, Jun 08, 2017 at 06:26:28PM +, Ilya Lesokhin wrote:
> Hi Kurt,
> I think this it's better to have this discussion in the kernel mailing list.
> But basically, we were debating this issue ourselves.
> Previously we had another field in the attach API which could be {SW only, HW
> only a
On Thu, Jun 08, 2017 at 10:43:15AM +0200, Hannes Frederic Sowa wrote:
>
> we have discussed this in the past on net...@vger.kernel.org but I just
> want to point out here again, that renewing the symmetric crypto keys is
> not supported in the kernel part (for the time being).
>
> So in case the
On Wed, Jun 07, 2017 at 03:35:45PM +0300, Boris Pismenny wrote:
> Hello all,
>
> I would like to introduce you to the new kernel API for TLS transmit-side
> data-path, and open a discussion regarding its support in OpenSSL.
So my understanding is that there are really 2 parts in the kernel
that c
On Thu, May 25, 2017 at 09:22:17PM +0200, Rainer Jung wrote:
>
> Should I open a GH issue or pull request for that trivial change?
Yes. Everything is required to be reviewed, and we use github for
that.
Kurt
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/
Google awarded us 1000 USD for the initial integration with
OSS-Fuzz. See
https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.html
I have asked Google to donate it to European Digital Rights (EDRi,
https://edri.org/). Google doubles the amount if you donate it to
a non-profit
On Tue, Feb 14, 2017 at 09:30:31AM +, Matt Caswell wrote:
> 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/bl
On Wed, Apr 19, 2017 at 02:57:13PM +0200, Stefan Eissing wrote:
>
> > Am 19.04.2017 um 14:14 schrieb Salz, Rich via openssl-dev
> > :
> >
> >> Out of curiosity, what's the ETA for TLS 1.3?
> >> [1] mentions April 5 as the release date (which was two weeks ago).
> >>
> >> [1]: https://blogs.akam
On Fri, Mar 24, 2017 at 12:22:14PM -0700, James Bottomley wrote:
>
> This is my understanding as well. From the GPL side, for both dynamic
> and static linking of openssl to GPLv2 code, the section 3 system
> exception applies.
Not everybody agrees that it applies.
Kurt
--
openssl-dev mailin
On Fri, Mar 24, 2017 at 08:02:25PM +0100, Florian Weimer wrote:
> * Quanah Gibson-Mount:
>
> > Zero people that I know of are saying to switch to the GPL. What is
> > being pointed out is that the incompatibility with the current
> > OpenSSL license with the GPLv2 has been a major problem.
>
> T
On Fri, Mar 24, 2017 at 11:43:17AM -0700, Quanah Gibson-Mount wrote:
> --On Friday, March 24, 2017 7:47 PM +0100 Kurt Roeckx
> wrote:
>
> > On Fri, Mar 24, 2017 at 10:18:40AM -0700, Quanah Gibson-Mount wrote:
> > > --On Friday, March 24, 2017 6:12 PM + &
On Fri, Mar 24, 2017 at 10:18:40AM -0700, Quanah Gibson-Mount wrote:
> --On Friday, March 24, 2017 6:12 PM + "Salz, Rich"
> wrote:
>
> > > Thanks Rich, that's a more useful starting point. Has dual licensing
> > > been considered? Both in 2015 and now, the lack of GPLv2 compatibility
> > >
On Fri, Mar 24, 2017 at 08:36:02AM +0100, Otto Moerbeek wrote:
> On Fri, Mar 24, 2017 at 08:21:49AM +0100, Marcus Meissner wrote:
>
> > On Fri, Mar 24, 2017 at 07:48:58AM +0100, Otto Moerbeek wrote:
> > > On Fri, Mar 24, 2017 at 04:11:48AM +, Blumenthal, Uri - 0553 - MITLL
> > > wrote:
> > >
On Mon, Mar 20, 2017 at 10:41:12PM +, Jason Vas Dias wrote:
> Hi - much thanks for many years of great OpenSSL releases,
> but this 1.1.0 branch, IMHO, should not be put above the 1.0.2k
> release on the website as the 'latest / best OpenSSL release' - this just
> wastes everybody's time . No
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, wine-base
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:
> >> > 1.0.2
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 268237
On Mon, Jan 02, 2017 at 08:50:24AM -0800, James Bottomley wrote:
> On Mon, 2017-01-02 at 17:38 +0100, Kurt Roeckx wrote:
> > On Sat, Dec 31, 2016 at 02:52:43PM -0800, James Bottomley wrote:
> > > This patch adds RSA signing for TPM2 keys. There's a limitation to
> >
On Sat, Dec 31, 2016 at 02:52:43PM -0800, James Bottomley wrote:
> This patch adds RSA signing for TPM2 keys. There's a limitation to the
> way TPM2 does signing: it must recognise the OID for the signature.
> That fails for the MD5-SHA1 signatures of the TLS/SSL certificate
> verification proto
On Thu, Nov 03, 2016 at 03:11:10PM -0500, Benjamin Kaduk wrote:
> To revitalize an old thread (quoted below but summarized here), some
> applications may desire source-code compatibility between the 1.0.2 API
> and the 1.1.0 API. It seems like the sense of the team is that such
> accessor function
On Fri, Nov 04, 2016 at 09:59:33PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-03 22:12:44 [+0100], Richard Levitte wrote:
> >
> > That would be quite a job. The correctness of the key can't be
> > discovered before the last encrypted block, where the decrypted
> > padding will either be
On Thu, Nov 03, 2016 at 01:53:56PM +0100, Richard Levitte wrote:
> Hi,
>
> I'm curious. Why exactly do you want to change the shared library
> version?
I had to change the soname in Debian (because I dropped all SSLv2
and SSLv3 symbols) and changed it to 1.0.2.
Kurt
--
openssl-dev mailing
On Tue, Oct 04, 2016 at 01:14:36PM +0100, David Woodhouse wrote:
>
> I would dearly have loved to make it, because I'd like to get some more
> detailed consensus on adding PKCS#11 support.
>
> In the past we've provisionally agreed on "let's do it after 1.1"... so
> now we should be looking at a
Hi,
Please read:
http://www.metzdowd.com/pipermail/cryptography/2016-September/030151.html
We use the same construct for our OPENSSL_cleanse, but I think we
also have assmebler versions.
Kurt
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4684
Please log in as guest with passwo
On Tue, Jan 19, 2016 at 07:25:04PM +, Kaduk, Ben via RT wrote:
> Part of the patch submitted to RT #844 includes a patch to the usage
> message of CA.pl. Although the functionality itself of CA.pl was
> rewritten for 1.1 (so that #844 was closed), the usage message remains
> incomplete, and De
On Thu, Aug 18, 2016 at 04:24:56PM +0200, Andy Polyakov wrote:
> >> I think you are assuming that ret is in the range [0, 2P), so that if
> >> you subtract P, the result would be in the range [0, P). That is the
> >> case in normal Montgomery multiplication, where the inputs are in the
> >> range [
On Sat, Aug 13, 2016 at 08:27:30PM -0700, Erik Forsberg wrote:
>
> just updated to developer studio 12.5 on Solaris 11.3
> I see lot of warnings when linking OpenSSL 1.1
> looking like these
>
> link_app.solaris-shared
> LD_LIBRARY_PATH=.: cc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THRE
On Thu, Jul 28, 2016 at 09:08:32AM -0700, John Denker wrote:
>
> That means the chip design is broken in ways that the manufacturer
> does not understand. The mfgr data indicates it "should" be much
> better than that:
> http://www.fdk.com/cyber-e/pdf/HM-RAE103.pdf
Reading that, you don't seem
On Thu, Jul 28, 2016 at 03:40:38PM -0700, Paul Dale wrote:
> I probably should have mentioned this in my earlier message, but the
> exponential example is valid for the NSIT SP800-90B non-IID tests too:
> 5.74889 bits per byte of assessed entropy. Again about as good a result as
> the tests wil
On Wed, Jul 27, 2016 at 05:32:49PM -0700, Paul Dale wrote:
> John's spot on the mark here. Testing gives a maximum entropy not a minimum.
> While a maximum is certainly useful, it isn't what you really need to
> guarantee your seeding.
Fom what I've read, some of the non-IID tests actually und
On Fri, Jul 22, 2016 at 10:16:16PM +, David Benjamin via RT wrote:
> On Fri, Jul 22, 2016 at 7:30 PM Hubert Kario via RT wrote:
>
> > On Friday, 22 July 2016 17:14:43 CEST Stephen Henson via RT wrote:
> > > On Fri Jul 22 14:56:11 2016, hka...@redhat.com wrote:
> > > > the issue is present in
On Fri, Jul 22, 2016 at 10:16:16PM +, David Benjamin via RT wrote:
> On Fri, Jul 22, 2016 at 7:30 PM Hubert Kario via RT wrote:
>
> > On Friday, 22 July 2016 17:14:43 CEST Stephen Henson via RT wrote:
> > > On Fri Jul 22 14:56:11 2016, hka...@redhat.com wrote:
> > > > the issue is present in
On Mon, Jul 11, 2016 at 02:53:05PM +0200, Mischa Salle wrote:
> Hi Richard, Mattias, others,
>
> I agree with you that it would be nice if OpenSSL could figure out
> itself whether a cert needs to be treated as a proxy, but currently that
> doesn't work reliably as far as I know.
> The flag is cer
On Mon, Jul 11, 2016 at 05:48:06PM +, Salz, Rich via RT wrote:
> Previously we've changed return-types from void to int. If there's still
> time, that seems like the thing to do here.
I've pushed a branched on github that at least does some of the
things. See github #1330.
Kurt
--
Tick
On Mon, Jul 11, 2016 at 05:48:06PM +, Salz, Rich via RT wrote:
> Previously we've changed return-types from void to int. If there's still
> time, that seems like the thing to do here.
I've pushed a branched on github that at least does some of the
things. See github #1330.
Kurt
--
opens
On Tue, Jul 19, 2016 at 02:12:41PM +, Matt Caswell via RT wrote:
>
> Is this still an issue? And if so are you able to provide a backtrace?
This might be a combination of kernel, glibc and gcc bugs, some of
which might have been fixed. In any case, I don't think it's an
openssl problem.
See
On Tue, Jul 19, 2016 at 02:12:41PM +, Matt Caswell via RT wrote:
>
> Is this still an issue? And if so are you able to provide a backtrace?
This might be a combination of kernel, glibc and gcc bugs, some of
which might have been fixed. In any case, I don't think it's an
openssl problem.
See
Hi,
When trying to check what happens if we simulate malloc()
returning NULL I'm running into a problem that I'm not sure how to
deal with.
We have CRYPTO_THREAD_run_once(), which takes an init() function
that returns void, so it can't return failures. At least the
pthread_once() function also h
On Sat, Jul 09, 2016 at 08:42:39PM +0200, c.hol...@ades.at wrote:
> Hi!
>
> I tried with Openssl 1.0.1t from current Debian testing.
> But I get
> undefined symbol: EVP_PKEY_CTX_set_rsa_oaep_md
1.0.1t is in stable, not testing.
1.0.1 doesn't have that function, 1.0.2 does.
Kurt
--
openssl-de
On Fri, Jul 08, 2016 at 05:43:21PM +0100, David Woodhouse wrote:
>
> This broke the OpenConnect VPN client, which now fails thus:
>
> DTLS handshake failed: 1
> 67609664:error:141640B5:SSL routines:tls_construct_client_hello:no ciphers
> available:ssl/statem/statem_clnt.c:927:
>
> I tried the n
On Thu, Jul 07, 2016 at 09:40:24PM +, Richard Levitte via RT wrote:
> On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> > /* Add to include/openssl/x509v3.h */
> >
> > void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
> > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);
On Thu, Jul 07, 2016 at 09:40:24PM +, Richard Levitte via RT wrote:
> On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> > /* Add to include/openssl/x509v3.h */
> >
> > void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
> > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);
In https://bugs.debian.org/828254, for the software "bro"
I got a request for accessors to:
- For OCSP_RESPID *rid:
- rid->type
- rid->value.byKey->length
- rid->value.byKey->data
- For OCSP_BASICRESP *basic:
- basic->certs
- basic->tbsResponseData->responderId
Kurt
--
Ticket here
Hi,
I received the following bug:
https://bugs.debian.org/829108
the HMAC manpage states:
HMAC_Init_ex() initializes or reuses a HMAC_CTX structure to use the
function evp_md and key key. Either can be NULL, in which case the
existing one will be reused.
However, the current code does
Hi,
I received the following bug in debian:
https://bugs.debian.org/829272
I got a lot of bugs filed about packages FTBFS with openssl 1.1.0.
I started to look at some of them, and many of them are due too
structures having been made opaque. In many cases accessors already
exists, but definitely
On Mon, Jun 27, 2016 at 08:50:43PM +, Thomas Waldmann via RT wrote:
> I didn't ask where to get the missing code from, I asked whether you
> maybe want to make life simpler for people by adding this to 1.0.x
> rather than having a thousand software developers copy and pasting it
> into their pr
Hi,
My last upload of openssl to experimental show this on hppa:
*** Error in `./asynctest': double free or corruption (out): 0x007307d8 ***
../util/shlib_wrap.sh ./asynctest => 134
# Failed test 'running asynctest'
# at ../test/testlib/OpenSSL/Test/Simple.pm line 77.
# Looks like you failed
On Tue, May 31, 2016 at 04:21:13PM +, ajai.mat...@wipro.com via RT wrote:
> Hi,
> We are facing an issue from the OpenSSL 1.0.2g ,after upgraded from OpenSSL
> 1.0.0s . [Linux version 2.6.24]
> When a https file transfer started with a Windows 7 application, we notice
> many TCP re-transmiss
On Mon, May 30, 2016 at 08:37:56PM +, Andy Polyakov via RT wrote:
> > I'm getting assembler errors on hppa that look like:
> > crypto/aes/aes-parisc.s: Assembler messages:
> > crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa'
> > crypto/aes/aes-parisc.s:7: Error: Unknown opcode: `a
On Mon, May 30, 2016 at 08:37:56PM +, Andy Polyakov via RT wrote:
> > I'm getting assembler errors on hppa that look like:
> > crypto/aes/aes-parisc.s: Assembler messages:
> > crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa'
> > crypto/aes/aes-parisc.s:7: Error: Unknown opcode: `a
Hi,
I'm getting assembler errors on hppa that look like:
crypto/aes/aes-parisc.s: Assembler messages:
crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa'
crypto/aes/aes-parisc.s:7: Error: Unknown opcode: `aes_encrypt'
crypto/aes/aes-parisc.s:11: Error: Missing function name for .PROC
cr
Hi,
I'm seeing this on powerpc:
../test/recipes/01-test_ordinals.t . ok
# Failed test 'check that there are no missing symbols in libcrypto.so'
# at ../test/recipes/01-test_symbol_presence.t line 112.
# Looks like you failed 1 test of 4.
../test/recipes/01-test_symbol_presence.t ..
D
Hi,
I'm getting:
crypto/chacha/chacha-s390x.S: Assembler messages:
crypto/chacha/chacha-s390x.S:7: Error: Unrecognized opcode: `clgije'
A full build log is available on:
https://buildd.debian.org/status/fetch.php?pkg=openssl&arch=s390x&ver=1.1.0~pre5-1&stamp=1464594754
Kurt
--
Ticket here:
On Sat, Apr 30, 2016 at 08:59:46PM +, Matt Caswell via RT wrote:
>
> This is not a bug in OpenSSL. The problem here is that the server is behaving
> incorrectly when receiving large ClientHello messages. The ClientHello is the
> first message that is sent from the client to the server. If a la
Hi,
I'm working on a tool that checks various things related to X509
certificates. I want to check that the encoding is actually
correct DER. With things like ASN1_TIME is seems easy to get to
the raw data, it just seems to contain it. But when I try it with
an ASN1_INTEGER it doesn't seem to c
On Mon, Mar 07, 2016 at 10:03:20PM +, David Benjamin via RT wrote:
> Session resumption involves a version check, so version negotiation must
> happen first. Currently, the DTLS implementation cannot do session
> resumption in DTLS 1.0 because the ssl_version check always checks against
> 1.2.
On Sat, Mar 19, 2016 at 07:41:28PM -0400, Jeffrey Walton wrote:
> On Sat, Mar 19, 2016 at 7:31 PM, Richard Levitte wrote:
> > In message on Sat, 19
> > Mar 2016 23:08:17 +, "noloa...@gmail.com via RT"
> > said:
> >
> > rt> On Sat, Mar 19, 2016 at 6:44 AM, Richard Levitte via RT
> > wrote
On Fri, Mar 18, 2016 at 01:18:04PM +, Matt Caswell wrote:
>
>
> On 18/03/16 12:52, noloa...@gmail.com via RT wrote:
> > I've configured with:
> >
> > ./config enable-afalgeng
> >
> > When I run the self tests, I see:
> >
> > ../test/recipes/30-test_afalg.t ... skipped: test_a
On Sun, Mar 13, 2016 at 02:09:34PM +, Olaf Kirfel via RT wrote:
> Hallo
> I am using Embarcadero/Borland C++-Builder for my personal interest and
> I have the problem, that after the update to openssl 1.0.2g the
> indy-components are not working.
> They are delivering an error message like "s
On Sun, Mar 13, 2016 at 11:27:23AM +, noloa...@gmail.com via RT wrote:
> >> static const uint64_t blake2b_IV[8] =
> >> {
> >> 0x6a09e667f3bcc908U, 0xbb67ae8584caa73bU,
> >> 0x3c6ef372fe94f82bU, 0xa54ff53a5f1d36f1U,
> >> 0x510e527fade682d1U, 0x9b05688c2b3e6c1fU,
> >> 0x1f83d9abfb
On Sun, Mar 13, 2016 at 07:15:52AM -0400, Jeffrey Walton wrote:
> On Sun, Mar 13, 2016 at 6:57 AM, Kurt Roeckx via RT wrote:
> > On Sun, Mar 13, 2016 at 10:30:54AM +, noloa...@gmail.com via RT wrote:
> >> crypto/blake2/blake2b.c:27: warning: integer constant is too large
On Sun, Mar 13, 2016 at 07:15:52AM -0400, Jeffrey Walton wrote:
> On Sun, Mar 13, 2016 at 6:57 AM, Kurt Roeckx via RT wrote:
> > On Sun, Mar 13, 2016 at 10:30:54AM +, noloa...@gmail.com via RT wrote:
> >> crypto/blake2/blake2b.c:27: warning: integer constant is too large
On Sun, Mar 13, 2016 at 10:30:54AM +, noloa...@gmail.com via RT wrote:
> crypto/blake2/blake2b.c:27: warning: integer constant is too large for
> 'unsigned long' type
That's a uint64_t. Why do you have an "unsigned long" as 64 bit
uint64_t?
Kurt
--
Ticket here: http://rt.openssl.org/Tick
On Sun, Mar 13, 2016 at 06:29:14AM +, noloa...@gmail.com via RT wrote:
> >> It looks like the hang is still present as of 603358d.
> >>
> >> When the following runs:
> >>
> >> ../test/recipes/30-test_afalg.t
> >>
> >> What is actually running? How can I get it under a debugger?
> >
> >
> >
On Sun, Feb 28, 2016 at 02:33:34PM +, Simon Richter via RT wrote:
> Hi,
>
> I just got this from our Jenkins instance that follows OpenSSL 1.0.2:
That should have been fixed some time ago, but it seems your mail
only got here today.
Kurt
--
Ticket here: http://rt.openssl.org/Ticket/Displ
On Wed, Mar 02, 2016 at 04:16:37PM +, noloa...@gmail.com via RT wrote:
> curve25519.c: In function 'table_select':
> curve25519.c:3323: warning: passing argument 2 of 'cmov' discards
That should be fixed shortly.
Kurt
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4369
Pleas
On Sun, Feb 28, 2016 at 12:17:41PM -0500, Jeffrey Walton wrote:
> On Sun, Feb 28, 2016 at 12:18 AM, Viktor Dukhovni
> wrote:
> >
> >> On Feb 27, 2016, at 7:42 PM, Jeffrey Walton wrote:
> >>
> >> Please ensure this is documented somewhere. I'm having trouble finding
> >> information on the new rul
On Sun, Feb 28, 2016 at 06:20:42AM -0700, The Doctor wrote:
> This cropped up this morning in
That was fixed an hour ago.
Kurt
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
1 - 100 of 614 matches
Mail list logo