It affects all 1.0.2 variants. I've a fix on github:
https://github.com/openssl/openssl/pull/1668
Cheers,
Richard
On Thu Oct 06 07:15:52 2016, valen...@astro.rug.nl wrote:
> Hi,
>
> While playing around with prime number generation I noticed that the
> following generates a core dump. I think
To be noted, there's more in section 2:
Most extant parsers ignore blanks at the ends of lines; blanks at the
beginnings of lines or in the middle of the base64-encoded data are
far less compatible. These observations are codified in Figure 1.
The most lax parser implementations are
On Mon Sep 26 14:34:17 2016, rs...@akamai.com wrote:
> We have a fix waiting for internal review; see GitHub issue 1546.
That's not related to this issue.
Cheers,
Richard
--
Richard Levitte
levi...@openssl.org
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4686
Please log in as
That has already been fixed in the 1.0.2 branch, and is part of 1.0.2j, which
was released today.
Cheers,
Richard
On Mon Sep 26 14:32:31 2016, jan-markus.pumpa...@bittium.com wrote:
>
>
> Hi,
>
> When building the OpenSSL 1.0.2i with -DHAVE_CRYPTODEV flag the build
> will fail in
Fix in place in master, OpenSSL_1_1_0-stable and OpenSSL_1_0_2-stable
Closing ticket.
Cheers,
Richard
On Fri Sep 02 14:57:41 2016, rs...@akamai.com wrote:
> Yeah, something like that for 1.0.2; simpler for 1.1.0. I'll do it.
>
--
Richard Levitte
levi...@openssl.org
--
Ticket here:
On Sat Sep 17 17:54:11 2016, pe...@lekensteyn.nl wrote:
> Hi,
>
> Commands which execute normally with OpenSSL 1.0.2h fail in OpenSSL
> 1.1.0. Presumably after the "Big apps cleanup (option-parsing, etc)",
>
> Options after parameters are no longer interpreted. For example,
> 'openssl dhparam 128
And finally got committed to master, with all suggested fixups.
Closing this ticket.
Cheers,
Richard
On Wed Sep 14 02:09:15 2016, levitte wrote:
> Issue 2 is implemented in https://github.com/openssl/openssl/pull/1572
>
> Please try it out.
>
> Cheers,
> Richard
>
> On Tue Sep 13 22:32:37 2016,
35inz1"
> >
> >
> > So looks good. One suggestion is to re-order the help output so it's
> > in declining "best to worst" 6 -> 5 -> 1 -> apr1 -> des), but that's
> > minor.
> >
> >
> > Cheers,
> > Brian
> >
> >
5 -> 1 -> apr1 -> des), but that's
> minor.
>
>
> Cheers,
> Brian
>
> On Tue, Sep 13, 2016 at 10:09 PM, Richard Levitte via RT
> <r...@openssl.org>
> wrote:
>
> > Issue 2 is implemented in
> > https://github.com/openssl/openssl/pull/1572
&g
Issue 2 is implemented in https://github.com/openssl/openssl/pull/1572
Please try it out.
Cheers,
Richard
On Tue Sep 13 22:32:37 2016, levitte wrote:
> Issue 1 now resolved, fix pushed to master branch as well as
> OpenSSL_1_1_0-stable.
>
> Issue 2 remaining.
>
> Cheers,
> Richard
>
> On Tue
Issue 1 now resolved, fix pushed to master branch as well as
OpenSSL_1_1_0-stable.
Issue 2 remaining.
Cheers,
Richard
On Tue Sep 13 20:32:18 2016, levitte wrote:
> I can confirm issue one and raise you one: it's not just on Windows
>
> On it.
>
> Cheers,
> Richard
>
> On Tue Sep 13 17:23:48
A note for the future: since this is really two issues, they should be one
ticket each. I'll let this one slip by, 'cause it's relatively simple to fix
both. However, please understand that while issue 1 will be fixed in OpenSSL
1.1.0a, issue 2 will not appear before OpenSSL 1.1.1.
Cheers,
I can confirm issue one and raise you one: it's not just on Windows
On it.
Cheers,
Richard
On Tue Sep 13 17:23:48 2016, bkhow...@gmail.com wrote:
> This may be two requests, one a bug and one a feature request.
>
> Issue 1: openssl 1.1.0 passwd on Windows 64 doesn't generate MD5 passwords
> (-1
Fixed in the 1.1.0 and 1.0.2 branches, as well as master.
Closing ticket. Thank you!
Cheers,
Richard
On Mon Nov 09 08:15:26 2015, dw...@infradead.org wrote:
> External engines such as engine_pkcs11 want to install into
> $ENGINESDIR. Would be nice if we could tell where it is by using
>
Thanks for the notification. Problem fixed, will be visible in a couple of
minutes.
Closing ticket
Cheers,
Richard
On Tue Sep 06 06:44:32 2016, tallev...@yahoo.com wrote:
> Hi,
> I've encountered the following error: "an error occurred while
> processing this directive" when
> opening the news
On Fri Sep 02 14:37:30 2016, rs...@akamai.com wrote:
> There is a bug. Navigate around and then right-click on the back
> button. All the pages just say openssl.
Errr, yes. That's because all pages include the same header, which has:
OpenSSL
I thought that was by design...
Cheers,
Richard
--
On Thu Sep 01 13:18:44 2016, stef...@sdaoden.eu wrote:
> Hello.
>
> From the documentation i cannot tell what is wrong with the
> following:
>
> echo abc > a; echo def > b; echo ghi > c
> openssl genpkey -algorithm RSA -out k.prv
> openssl pkey -in k.prv -pubout -out k.pub
> openssl dgst -sha512
On Thu Sep 01 13:13:44 2016, stef...@sdaoden.eu wrote:
> Before sending the last message i looked around on the website (it
> has become particularly complicated to find the bug tracker), and
> looking at the "go-back" list i saw dozens of "OpenSSL" entries,
> rather than rt, "Getting started as a
Curious. The diverse flags for the aix config targets' information in 1.1.0 are
exact copies from the 1.0.x series...
The best way you can help out here is to show us the build command lines you
got for building crypto/ppccap.o in both 1.1.0 and 1.0.2, so we can see what
actually differs.
Haven't heard if this worked for you, John... the change has been reviewed and
is now merged into master and the 1.1.0 release branch, so I'll close this
ticket. If you have further problems, please report anew.
Cheers,
Richard
On Tue Aug 30 16:44:08 2016, levitte wrote:
>
https://github.com/openssl/openssl/pull/1519
Cheers,
Richard
On Tue Aug 30 09:35:42 2016, levitte wrote:
> Good find. I'll fix.
>
> Cheers,
> Richard
>
> On Mon Aug 29 22:06:51 2016, jvea...@gmail.com wrote:
> > I have a Windows machine where Perl is installed in "C:\Program
> >
Good find. I'll fix.
Cheers,
Richard
On Mon Aug 29 22:06:51 2016, jvea...@gmail.com wrote:
> I have a Windows machine where Perl is installed in "C:\Program
> Files\Perl64\bin\perl.exe".
>
>
>
> When executing "perl Configure VC-WIN32", I get the following error
>
>
>
> 'C:\Program' is not
On Mon Aug 29 12:27:59 2016, appro wrote:
> > With the current build system, user-defined CFLAGS are accepted as
> > any
> > unrecognized command line argument passed to Configure. This seems a
> > little dangerous to me since it means a simple typo could end up
> > getting passed to the C
This has now been merged into the master branch, and will be part of version
1.1.0.
Cheers,
Richard ( closing ticket )
On Wed Aug 24 11:32:54 2016, levitte wrote:
> After much internal deliberation, we ended up checking __GNUC__ rather
> than
> dissing __SUBPRO_C. Our hope is that a compiler
After much internal deliberation, we ended up checking __GNUC__ rather than
dissing __SUBPRO_C. Our hope is that a compiler that implements GNU extensions
will also define __GNUC__. Our checks of the Intel compiler (which someone
referred to) does so, for example (if I understood correctly).
Ok. I'm going with that solution, then. See attached diff.
Cheers,
Richard
On Wed Aug 17 21:21:34 2016, yoi_no_myou...@yahoo.co.jp wrote:
> Yes, __SUNPRO_C is defined by DeveloperStudio compiler.
>
> > To only allow the use of __atomic_add_fetch when __ATOMIC_RELAXED is
> > non-zero
>
> > isn't
This was merged yesterday. Please try out a new snapshot. Closing this ticket.
Cheers,
Richard
On Fri Aug 19 15:08:29 2016, levitte wrote:
> Please try out this github pull request:
> https://github.com/openssl/openssl/pull/1470
>
> Cheers,
> Richard
>
> On Fri Aug 19 14:40:02 2016, levitte
:12:58 2016, beld...@gmail.com wrote:
> > Dear Richard,
> >
> > Thank you, it works.
> >
> > On Mon, Aug 22, 2016 at 4:00 PM, Richard Levitte via RT
> > <r...@openssl.org>
> > wrote:
> >
> > > The issue isn't with the pre-created key,
:00 PM, Richard Levitte via RT
> <r...@openssl.org>
> wrote:
>
> > The issue isn't with the pre-created key, but because '-x509' doesn't
> > fully
> > flag that something new is to be created. The freeze is because
> > 'openssl
> > req'
> > tries to rea
The issue isn't with the pre-created key, but because '-x509' doesn't fully
flag that something new is to be created. The freeze is because 'openssl req'
tries to read a csr... '-newkey', however, does flag the creation of a csr /
x509, that's why the alternative command works.
Fix in
Please try out this github pull request:
https://github.com/openssl/openssl/pull/1470
Cheers,
Richard
On Fri Aug 19 14:40:02 2016, levitte wrote:
> We totally missed out on adapting util/mk1mf.pl. Fix on its way.
>
> On Fri Aug 19 14:20:20 2016, simon.rich...@hogyros.de wrote:
> > Hi,
> >
> >
We totally missed out on adapting util/mk1mf.pl. Fix on its way.
On Fri Aug 19 14:20:20 2016, simon.rich...@hogyros.de wrote:
> Hi,
>
> the 1.0.2 branch fails to compile for me:
>
> link /nologo /subsystem:console /opt:ref /debug
> /out:out32dll\dtlstest.exe @C:\Windows\TEMP\nm8D73.tmp
> Creating
On Fri Jul 08 09:36:42 2016, levitte wrote:
> On Fri Jul 08 09:33:01 2016, noloa...@gmail.com wrote:
> > Hmmm... If I want to use ld.gold as my linker, the easiest path is to
> > set LD=ld.gold. It makes perfect sense to some
>
> Did it work for you when doing this?
>
> ./config -fuse-ld=gold
To only allow the use of __atomic_add_fetch when __ATOMIC_RELAXED is non-zero
isn't the right move here. So it seems that different compilers either only
implement a subset of the __atomic builtins, or name them differently.
What was the macro defined by the DeveloperStudio compiler? __SUNPRO_C
On Mon Aug 01 16:50:21 2016, matt wrote:
> On Mon Jul 25 08:49:27 2016, matt wrote:
> > Ping Jeff?
>
> Ping again?
>
> Matt
It's worth mentioning that time is getting short, next beta in a few days,
final in 3 weeks.
--
Richard Levitte
levi...@openssl.org
--
Ticket here:
On Fri Jul 22 14:09:12 2016, steve wrote:
> On Sat Jun 25 22:09:59 2016, open...@roumenpetrov.info wrote:
> >
> > Above is reason the request to remove const from return argument of
> > get0
> > methods.
> >
>
> We had a discussion about this and the preference was to have get
> methods
> retain
On Mon Jul 25 15:11:10 2016, levitte wrote:
> On Mon Jul 25 14:28:04 2016, levitte wrote:
> > BUT... I'm realising that when you do recognise a GT3 proxy (I think
> > I've seen
> > check_issued functions being used for that), there's no way for
> > external code
> > to set the proxy path length
On Mon Jul 25 14:28:04 2016, levitte wrote:
> BUT... I'm realising that when you do recognise a GT3 proxy (I think
> I've seen
> check_issued functions being used for that), there's no way for
> external code
> to set the proxy path length for the certificate in question. While
> that's fine
> for
On Mon Jul 25 12:39:43 2016, msa...@nikhef.nl wrote:
> Hi Richard,
>
> On Mon, Jul 25, 2016 at 11:46:50AM +, Richard Levitte via RT
> wrote:
> > Is that code to cope with pathlen checking bugs? That's what it looks
> > to me. In
> > that case, it might no lon
On Mon Jul 25 11:32:17 2016, msa...@nikhef.nl wrote:
> On Sat, Jul 23, 2016 at 09:44:18AM +0000, Richard Levitte via RT
> wrote:
> > To get current_cert, it's X509_STORE_CTX_get_current_cert().
> > To get current_issuer, it's X509_STORE_CTX_get0_current_issuer()
>
> Hi R
rid/voms/blob/master/src/sslutils/sslutils.c
> and many other places for verifying the proxy chain or is there a
> better/other solution for that?
>
> Best wishes,
> Mischa
>
> On Fri, Jul 22, 2016 at 03:26:26PM +, Richard Levitte via RT
> wrote:
> > In addition
Now part of master, commit 8b9546c7085733c88f1df66da48d48a3bc5230a2
Cheers,
Richard
On Fri Jul 22 19:53:01 2016, levitte wrote:
> It's a spelling error. Fix in https://github.com/openssl/openssl/pull/1341
>
> Cheers,
> Richard
>
> On Wed Jul 20 21:45:53 2016, c...@five-ten-sg.com wrote:
> >
It's a spelling error. Fix in https://github.com/openssl/openssl/pull/1341
Cheers,
Richard
On Wed Jul 20 21:45:53 2016, c...@five-ten-sg.com wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Source from master on github,
>
> ./Configure --prefix=/usr/local
On Fri Jul 22 12:52:18 2016, rs...@akamai.com wrote:
> And now, with subject clearly stated, I think we should not do this.
After some discussion, we decided to abandon this line of thought and get back
to accessors as off RT4602.
Closing this ticket.
--
Richard Levitte
levi...@openssl.org
--
r verifying the proxy chain or is there a
> better/other solution for that?
>
> Best wishes,
> Mischa
>
> On Fri, Jul 22, 2016 at 03:26:26PM +, Richard Levitte via RT
> wrote:
> > In addition to github PR 1294, there's now also PR 1339 which adds
> > the function to set the EXFLAG_
In addition to github PR 1294, there's now also PR 1339 which adds the function
to set the EXFLAG_PROXY flag on a given certificate.
Also, PR 1295 has been updated. Instead of a function that returns a lock,
there is now a lock and an unlock function.
To me, it seems that that covers what's
Forgive me for being sloppy, I forgot to add a subject. Now added, it says what
the actual issue is.
On Fri Jul 22 11:32:27 2016, levitte wrote:
> Ticket derived from RT4602 (missing accessors)
>
> Reports have been coming in that in the grid world, there are two pre-
> rfc3820
> forms of proxy
Ticket derived from RT4602 (missing accessors)
Reports have been coming in that in the grid world, there are two pre-rfc3820
forms of proxy certs still being used.
Old (pre-draft) format: Looks like a regular EE cert, but has been issued by
another EE (real or proxy), and can be recognised by
On Fri Jul 22 07:38:25 2016, mattias.ell...@physics.uu.se wrote:
> tor 2016-07-21 klockan 09:51 + skrev Richard Levitte via RT:
> > On Thu Jul 21 08:18:30 2016, mattias.ell...@physics.uu.se wrote:
> > >
> > > ons 2016-07-20 klockan 15:14 +0000 s
On Thu Jul 21 08:18:30 2016, mattias.ell...@physics.uu.se wrote:
> ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT:
> > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> > >
> > > I guess having a more restrictive accessor that only sets
On Tue Jul 19 17:47:43 2016, levitte wrote:
> On Tue Jul 19 16:41:13 2016, k...@roeckx.be wrote:
> > 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.
>
On Wed Jul 20 16:58:20 2016, janj...@nikhef.nl wrote:
> Hi Richard,
>
> On 20/07/16 17:14, Richard Levitte via RT wrote:
> > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> >> I guess having a more restrictive accessor that only sets the
> >&g
On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> I guess having a more restrictive accessor that only sets the
> EXFLAG_PROXY bit could work. I suggested the more general solution of
> having set/clear accessors for arbitrary flags since it was - well
> more
> general.
So let me
On Mon Jul 11 14:04:22 2016, dw...@infradead.org wrote:
> I was using store.get_issuer() in OpenConnect too, because I need to
> manually build the trust chain to include it on the wire — because
> even today the server might *still* suffer RT#1942 and fail to trust
> our client cert unless we
On Tue Jul 19 16:41:13 2016, k...@roeckx.be wrote:
> 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
On Tue Jul 19 15:36:04 2016, levitte wrote:
> Ok, so the other way I can think of is a bit ugly, but... using oob
> data, in
> this case a variable that the init routine must set to signal that
> everything
> went well. I'm thinking a variable in CRYPTO_THREAD_run_once() that
> gets passed
> by
On Tue Jul 19 15:36:04 2016, levitte wrote:
> To be noted is that we never check the value CRYPTO_THREAD_run_once()
> returns... Should we make it __owur?
I spoke too fast. We do... just not always.
--
Richard Levitte
levi...@openssl.org
--
Ticket here:
On Tue Jul 19 15:26:58 2016, matt wrote:
>
>
> On 19/07/16 16:23, Richard Levitte via RT wrote:
> > On Mon Jul 11 16:20:29 2016, k...@roeckx.be wrote:
> >> Hi,
> >>
> >> When trying to check what happens if we simulate malloc()
> >> returning NU
On Mon Jul 11 16:20:29 2016, k...@roeckx.be wrote:
> 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
On Mon Jul 11 17:48:06 2016, rs...@akamai.com 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 agree.
--
Richard Levitte
levi...@openssl.org
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4614
Please
On Tue Jul 19 14:01:17 2016, matt wrote:
>
>
> On 19/07/16 14:41, Richard Levitte via RT wrote:
> > Hi Jeff,
> >
> > I'm going to assume that a newer checkout of the master branch won't
> > change
> > much, so if you please, try this command and send mack
Hi Jeff,
I'm going to assume that a newer checkout of the master branch won't change
much, so if you please, try this command and send mack the result:
make test TESTS='test_afalg test_rehash'
Cheers,
Richard
On Thu Jun 23 11:10:04 2016, noloa...@gmail.com wrote:
> I'm working on a Debian X32
My answer was incorrect...
What happens when trying to find a CRL is that get_cert_by_subject (in
crypto/x509/by_dir.c) gets called, and it will try to load every file it finds
(so both $hash{sub_ca}.r0 and $hash{sub_ca}.r1). However, when trying to
storing them in the internal store, it will
So let me see if I understand this correctly... $hash(sub_ca).r1 and
$hash(sub_ca).r0, being of the same sub_ca, will of course have the same issuer
name. Right?
Unless I misread the source, OpenSSL will actually load both files. However,
since both CRLs have the same issuer, and cached CRLs are
On Sun Jul 10 19:38:03 2016, ms...@barracuda.com wrote:
> OpenSSL 1.0.2h
>
> The function eckey_priv_encode() may crash if the same pkey is
> serialized from multiple threads. Here is a sample backtrace:
>
> #0 0x7fff8f321f92 in _platform_memmove$VARIANT$Haswell ()
> #1 0x000100196132 in
On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> fre 2016-07-08 klockan 00:42 +0200 skrev Kurt Roeckx:
> > Mattias,
> >
> > Can you explain why this is needed, what the code is trying to do?
> >
> >
> > Kurt
> >
>
> Hi!
>
> The modification of the extension flags happens in at
On Fri Jul 08 09:33:01 2016, noloa...@gmail.com wrote:
> Hmmm... If I want to use ld.gold as my linker, the easiest path is to
> set LD=ld.gold. It makes perfect sense to some
Did it work for you when doing this?
./config -fuse-ld=gold
--
Richard Levitte
levi...@openssl.org
--
Ticket
On Fri Jul 08 07:47:14 2016, noloa...@gmail.com wrote:
> $ ./config LD=ld.gold
> Operating system: x86_64-whatever-linux2
> Configuring for linux-x86_64
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> target already defined - linux-x86_64 (offending arg: LD=ld.gold)
>
> And:
>
> $
On Thu Jul 07 21:29:09 2016, levitte wrote:
> On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> > /* Add to include/openssl/x509_vfy.h : */
> >
> > typedef int (*X509_STORE_CTX_get_issuer)(X509 **issuer, X509_STORE_CTX
> > *ctx, X509 *x);
> > typedef int
On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> /* Add to some header file */
>
> CRYPTO_RWLOCK *X509_STORE_get_lock(X509_STORE *ctx);
>
> /* Add to some implementation file */
>
> /* Add to crypto/x509/x509_lu.c */
>
> CRYPTO_RWLOCK *X509_STORE_get_lock(X509_STORE *v)
> {
> return v->lock;
>
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);
>
>
> /* Add to crypto/x509v3/v3_purp.c */
>
> void X509_set_extension_flags(X509
On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> /* Add to include/openssl/x509_vfy.h : */
>
> typedef int (*X509_STORE_CTX_get_issuer)(X509 **issuer, X509_STORE_CTX
> *ctx, X509 *x);
> typedef int (*X509_STORE_CTX_check_issued)(X509_STORE_CTX *ctx, X509
> *x, X509 *issuer);
>
> void
On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> 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
On Tue Jul 05 22:38:44 2016, ncarb...@prodigitalsoftware.com wrote:
> Knowing that made all the difference, thank you. It wasn't clear since
> there's some evidence of "2.0" in the various downloads.
That's "openssl-fips" which is a FIPS module. Separate thing with its own
versioning.
--
Richard
What part of this is a bug in OpenSSL proper?
To me it looks like the classic issue when linking with static libraries, that
you have to explicitely specify the libraries that libcrypto and libssl depend
on.
Cheers,
Richard
On Mon Jul 04 23:40:25 2016, noloa...@gmail.com wrote:
> From
On Fri Jul 01 23:31:45 2016, noloa...@gmail.com wrote:
> On Wed, Jun 29, 2016 at 5:19 PM, Richard Levitte via RT
> <r...@openssl.org> wrote:
> > This has nothing to do with Windows 10 per se, it's the space-in-
> > directory
> > issue that's come back.
> > I
That's correct for 1.1.0. install_sw honors --prefix. We made that change to
get away from all the weird magic around the combinations of --prefix and
--openssldir that happened in previous versions.
In other words, it's not a bug, it's a feature. Closing this ticket.
Cheers,
Richard
On Thu Jun
On Wed Jun 29 21:16:31 2016, levitte wrote:
> On Mon Jun 20 19:37:41 2016, levitte wrote:
> > On Tue Feb 02 01:44:47 2016, openssl-dev@openssl.org wrote:
> > > On Mon, Feb 01, 2016 at 07:18:04PM +, Rich Salz via RT wrote:
> > >
> > > > This is reported against 0.9.x; please open a new ticket
This has nothing to do with Windows 10 per se, it's the space-in-directory
issue that's come back.
I'm working on a solution that should avoid that problem more consistently,
going forward.
Cheers,
Richard
On Wed Jun 29 09:04:12 2016, noloa...@gmail.com wrote:
> Working on a Windows 10, 32-bit
On Mon Jun 20 19:37:41 2016, levitte wrote:
> On Tue Feb 02 01:44:47 2016, openssl-dev@openssl.org wrote:
> > On Mon, Feb 01, 2016 at 07:18:04PM +, Rich Salz via RT wrote:
> >
> > > This is reported against 0.9.x; please open a new ticket if still a
> > > problem
> > > with current releases.
>
Like Rich says, our build system in 1.0.2 doesn't support parallell building or
testing. For upcoming 1.1.0, the build system has been remade from the ground
up, with parallell building in mind. Parallell testing hasn't been tested there
either, though... it might work, it might not. However, the
On Tue Feb 02 01:44:47 2016, openssl-dev@openssl.org wrote:
> On Mon, Feb 01, 2016 at 07:18:04PM +, Rich Salz via RT wrote:
>
> > This is reported against 0.9.x; please open a new ticket if still a
> > problem
> > with current releases.
>
> The same behaviour is present in all releases
Thanks.
Fixup currently in https://github.com/openssl/openssl/pull/1220, pending
approval.
Cheers,
Richard
On Thu Jun 16 02:29:22 2016, simon.rich...@hogyros.de wrote:
> Hi,
>
> the 1.0.2 branch fails to compile on VC-WIN32:
>
> .\apps\speed.c(335): error C2065: 'err': undeclared identifier
>
>
Cool. That closes this ticket.
BTW, you're right, we don't honor a CFLAGS env var. We never did. We take the
cflags on the configuration command line.
Cheers,
Richard
On Tue Jun 14 07:35:11 2016, noloa...@gmail.com wrote:
> On Tue, Jun 14, 2016 at 3:33 AM, Richard Levitte via RT
&
Is this enough to satisfy you?
./config -DNDEBUG -g3 -O0
On Tue Jun 14 07:24:31 2016, noloa...@gmail.com wrote:
> Working from latest sources. I'm trying to build a "debug"
> configuration with both -DNDEBUG (I don't want asserts firing) and -g3
> (I want the symbolic constants).
>
> $ ./config
Apologies for the delay before responding.
I believe we have fixed that by replacing 'chomp' with 's|\R$||' in the master
branch.
It this is still an issue, please open a new ticket.
Cheers,
Richard
On Mon Mar 30 07:51:29 2015, esado...@eniks.com wrote:
> It is well known issue with build on
Thank you! Found the tests that generated this and made sure the temporary
files get removed.
Please get a fresh checkout of the master branch and check again.
Closing this ticket.
Cheers,
Richard
On Thu Jun 02 15:50:32 2016, stef...@sdaoden.eu wrote:
> Yep:
>
> -rw--- 1 steffen steffen
On Thu Jun 02 15:50:31 2016, stef...@sdaoden.eu wrote:
> Hello.
>
> I have never seen something like this:
>
> Parser.c: loadable library and perl binaries are mismatched (got
> handshake key 0xdb00080, needed 0xdb80080)
>
> This is v5.24 on a Linux system, and it flawless afaik.
Are you sure
On Thu Jun 02 15:50:31 2016, stef...@sdaoden.eu wrote:
> Oh yes, please!
The 'install' target calls three other targets:
install_sw
install_ssldirs
install_docs
So if you simple do 'make install_sw' or 'nmake install_sw', I think you'll get
what you want.
Closing this ticket.
--
Richard
Applied and merged into master. Thank you.
Closing this ticket.
Cheers,
Richard
On Wed Jun 01 22:31:14 2016, sebast...@breakpoint.cc wrote:
> On 2016-05-30 21:28:06 [+], Andy Polyakov via RT wrote:
> > For what it's worth I can't reproduce problem on Fedora or RedHat.
>
> The test
> |…
> |#
On Wed Jun 01 22:45:08 2016, noloa...@gmail.com wrote:
> On Wed, Jun 1, 2016 at 4:47 PM, Richard Levitte via RT
> <r...@openssl.org> wrote:
> > Please give us the full configuration command you used, including
> > environment
> > variables that may affect it. Just th
Does it make a difference if you add 'no-sse2' to your configuration command?
On Wed Jun 01 21:22:24 2016, noloa...@gmail.com wrote:
> On Wed, Jun 1, 2016 at 4:47 PM, Richard Levitte via RT
> <r...@openssl.org> wrote:
> > Please give us the full configuration command y
Please give us the full configuration command you used, including environment
variables that may affect it. Just the presence of '-ansi' tells me that you
didn't just say './config' without any arguments.
On Wed Jun 01 19:54:51 2016, noloa...@gmail.com wrote:
> So testing with 1.1.0-pre6 from 1
Please try this and send us the result:
make test TESTS=test_afalg VERBOSE=1
On Wed Jun 01 19:15:47 2016, noloa...@gmail.com wrote:
> It looks like there's still some problems with our old friend afalgtest.
>
> Below is from 1.1.0-pre6 on 1 JUN 2016
>
> **
>
> $ cat gentoo-result.txt
> (
This has been fixed in commit 7233bea263
Closing this ticket.
Cheers,
Richard
On Wed May 25 21:46:01 2016, levitte wrote:
> I don't get such warnings. Can you tell me what system and with what
> tool chain
> (including versions)?
>
> On Sun Mar 20 13:07:43 2016, noloa...@gmail.com wrote:
> >
That hex key string looks off. It seems to include an ending \n (0a), which I
suspect is because at an earlier time, someone forgot to peal off the ending
linefeed. Take away the endine 0a and I'm sure things will be fine.
The 'set_hex' check is exactly the same in the 1.0.1, 1.0.2 and upcoming
On Tue May 31 18:26:56 2016, rs...@akamai.com wrote:
> Since it 'just works' for now, maybe remove the 1.1 milestone?
>
I agree. Making it post-1.1.0
--
Richard Levitte
levi...@openssl.org
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4457
Please log in as guest with password
On Tue May 31 18:04:39 2016, rsalz wrote:
> Is this *literally* a Fedora 1 machine? If so, then I'm inclined to
> close this
> as it went end-of-life more than 12 years ago.
On the other hand, according to The Open Group, sys/select.h should be included
to get select() and all things belonging
On Tue May 31 17:14:12 2016, rsalz wrote:
> We fixed the naming issue for unlink et al. Can this ticket be closed?
I'll do another check, just to make sure.
--
Richard Levitte
levi...@openssl.org
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4487
Please log in as guest with
We have rejected it a number of times. Doing so again. Please do not respond to
this ticket again.
On Tue May 31 17:00:39 2016, rsalz wrote:
> So this got tagged with the 1.1 milestone. What exactly is there for
> us to do
> here?
> The header files without 'extern "C"' are all okay, they just
1 - 100 of 847 matches
Mail list logo
