Well, it is a SHOULD not a MUST. But point taken it could be (much) better :)
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4698
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-d
I think you are reading too much into Viktor's words. From my perspective he
was proposing a work-around, nothing more.
Yeah, what we did is sub-optimal. Not the first time, won't be the last :)
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4697
Please log in as guest with pass
Try putting a "dir" command before the openssl command, to make sure that the
file exists.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4676
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listi
You did not cut/paste the command line properly because you wrote "-in -inkey"
which is wrong. Or maybe that is your error?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4676
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: ht
We have a fix waiting for internal review; see GitHub issue 1546.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4686
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
We do have assembler versions for most CPI's.
Closing ticket.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4684
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Errr, yes. That's because all pages include the same header, which has:
>
> OpenSSL
>
> I thought that was by design...
No, it was because the person who rebuilt the web doesn't know much about the
web.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4668
Please log in as gues
Yeah, something like that for 1.0.2; simpler for 1.1.0. I'll do it.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4669
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
There is a bug. Navigate around and then right-click on the back button. All
the pages just say openssl.
Re-opening.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4668
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://m
Can you please provide some concrete examples, so I know what to look for and
fix? (I'm kinda slow sometimes)
Thanks!
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4668
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://
From: Sunil Singh [mailto:ekodevelop...@gmail.com]
Sent: Saturday, August 27, 2016 2:42 AM
To: Salz, Rich; openssl-secur...@openssl.org
Subject: Re: [openssl-security] Multiple issue with BIO_new_file Internal
function (potential stack overflow/Crash)
I don't think its right to say that its not
Try it, it will be a huge invasive change.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Why do you have to trust root CAs? Why can't you trust at a lower level, e.g.
> an intermediate CA or even a leaf certificate that is not a CA at all?
I said CA's, not root CA's.
As Viktor pointed out, this doesn't work in 1.0.1
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=464
I am not sure what to suggest. This conversation is bouncing across two ticket
systems and is all about a legacy certificate format that is, what, outdated
since 2002?
I am hard-pressed to see why OpenSSL 1.1 has to do anything other than what
Richard proposed.
--
Ticket here: http://rt.open
> That's exactly what we currently do, we provide a verification callback, but
> we do need to be able to set the failing cert in a chain for that.
Stick it in EXDAT?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted
--
op
Perhaps the GRID folks can just write their own validation routine completely?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl
And now, with subject clearly stated, I think we should not do this.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4622
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> OCSP responses do not seem to include the intermediate certificates so they
> have to be acquired in other ways. I have been doing this and adding them
> to the certificate stack handed to OCSP_basic_verify().
Perhaps adding them to X509_STORE or STORE_CTX directly?
> I am relatively new to
Previously we've changed return-types from void to int. If there's still time,
that seems like the thing to do here.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4614
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mt
Can you use a more recent version? 1.0.1 is end of life and only getting
security fixes (and then only for the rest of the year).
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4613
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe
> These APIs are documented as thread safe, and should not change the
> internal flags of the pkey without proper locking.
Where is that?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4611
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To uns
I don't know what you expect us to do. We don't use the LD variable.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4609
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
I think we should ask kurt to ask the original reporter what they need to do.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-de
I don't know what 1.1 beta source you downloaded. The code on GitHub is the
latest version of what will be 1.1 It *is* fixed, just later than the version
you downloaded.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606
Please log in as guest with password guest if prompted
> I don't want either of them. I only want to install the library in the
> directory of
> my choosing :)
#! /bin/sh
make $* && cp *.a $MYDIR
Less flippantly, not everything is supported :)
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4601
Please log in as guest with password g
> and you will not accept pull requests that do that?
So far, the team is not interested in doing that. Features are not added to
stable branches. But, for myself, I would like to see something like a GitHub
repo that built on top of 1.0.2 and made the 1.1 API's available. I think that
for mo
> Also, under the x86 no problem.Now how to solve this problem?
The same way you debug any C problem. Start by running it under the debugger?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4587
Please log in as guest with password guest if prompted
--
openssl-dev mailing
> But obviously I was expecting too much...
Sorry you're not pleased. Not sure what to say -- you get what you pay for?
Maybe someone will come up with a "openssl-102-compat" package?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4589
Please log in as guest with password guest
> Guess problem is caused by the CPU architecture.The same example, arm
> and x86 result is different.hope to receive your reply very much!
Yes it probably is.
What did you change to make it compile?
The demo's are mostly old and broken, and in the next release most of them are
gone. Looks in
You missed SSL_CTX_set_app_data :)
I'll fix this as part of another doc fix which is being reviewed now.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4592
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/
Is this using 1.0.1?
Please try to do it with 1.0.2 or master.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4587
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Yes, it should not crash. But without more information it is hard/impossible
to debug.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4580
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo
Having a mix of experied and unexpired certificates in the trust store for the
same issuer/key seems to be undefined. I am not sure this is a bug.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4580
Please log in as guest with password guest if prompted
--
openssl-dev mailing li
This is not supported.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4581
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Need more information, like a full backtrace and how to reproduce it.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4579
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Sending mail re-opens the ticket.
Rats, wish it was fixed. Going to need something to more easily reproduce it,
I guess.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https
I don't think this will get fixed for 1.1
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4576
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Ah, didn't realize you needed it in 1.0.2; will backport shortl.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> It still seems like pqueue out to be excised from the source base and replace
> with something simpler.
Agree.
Could you go to Github and open an issue on this?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4558
Please log in as guest with password guest if prompted
--
open
Not defined means we make no guarantees. OpenSSL can depend on what it knows
to be true. In the next release we can revisit this.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscr
So are we still fixing SSLv2 bugs? Or are they too low on the priority list?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4038
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-de
> That's fine with me, though, it might bite someone in the future. Is there any
> documentation or site listing which funcs would be thread-safe? (if this is
> offtopic, please let me know, and we'll simply end the thread)
Please take it to openssl-dev mailing list. It's a good discussion to hav
Doesn't it make more sense to have a single API that returns the
platform-specific flags?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listin
> If the size multiplier is changed to, say, 4, then the problem goes away with
> no apparent ill effects. Reading the code for set_hex() and its caller, it
> does
> not appear that the size multiplier is related to a buffer size or some other
> limitation.
Yes it is, it's the size of the buffer
Since it 'just works' for now, maybe remove the 1.1 milestone?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4457
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
I completely agree that nameconstraints are going to become a bigger deal,
likely in the next 12-24 months, and certainly during the peak usage time of
OpenSSL 1.1
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3502
Please log in as guest with password guest if prompted
--
ope
> Note that other implementations treated this as a bug and fixed it a long time
> ago.
What other implementations, and what did they do? Always treating a CN as a
DNS name? We can't.
> I'm not sure what "deprecated" and "mandated" mean in the openssl
> context. If openssl actually de-impleme
It's probably not an issue because the number of file descriptors has increased
on the native O/S's. But "file descriptor exhaustion" is still an issue for
RNG's (google it) and we should keep it in mind for the future. What's the
best way to do that?
--
Ticket here: http://rt.openssl.org/T
1.0.1 is at end-of life and is only getting security fixes for the rest of the
year.
1.0.2 is LTS and maybe this needs to be ported there (and master) as well?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4522
Please log in as guest with password guest if prompted
--
openssl
> Since this is a MS IIS 7.0 server I would argue that it'd be in the interest
> of
> openssl to handle the situation rather than accept this scenario - since IIS
> is
> likely powering more than a few hosts?
It's a known bug, and openssl can work-around the bug by configuring as
described.
That code is still wrong. Once you "get0" something you can only look at it.
You cannot pass it off to a "set0" function. Get0 gives you a pointer that
*you do not own* and *set0* takes a pointer that you DO own and are giving
away. You can't give away something that isn't yours :)
The erro
> RSA_get0_key(rsa, n, e, NULL); /* note this is a GET0 */
> /* other stuff done, such as calculating d */ RSA_set0_key(rsa, n, e, d);
>
> rsa is left with n and e pointing to unallocated storage.
That code is incorrect.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4518
Please
> I can live with it.
> The only solution without some type of change was :
>
> RSA_set0_key(rsa, n, e, NULL);
> /* other stuff done, such as calculating d */
> n_new = BN_dup(n);
> e_new = BN_dup(e);
> RSA_set0_key(rsa, n_new, e_new, d);
>
> It is really gross, and is no
> Thanks for registering, when I can expect first your feedback on this bug?
This is a mostly volunteer open source project. So hopefully soon is the best
you can expect.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4519
Please log in as guest with password guest if prompted
Why do you want GCM then?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4521
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Yes, but this difference adds convenience, IMHO. My preference is this:
> RSA_set0_key(rsa, n, e, d); with any parameter (except for rsa :) potentially
> NULL.
This defeats a main point: partial construction is a bad thing.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4518
Pl
> Should I make similar in https://rt.openssl.org/ or it is enough to have in
> github.com?
We prefer bug reports in RT, not as issues. PR's on GitHub are fine.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4519
Please log in as guest with password guest if prompted
--
openssl
No, he means setting the same value twice. For example, making this change:
If (r=->n != n) BN_free(r->n);
If(r->e != e) BN_free(r->e);
If (r->d != d) BN_free(r->d);
I agree it shouldn't happen, but do we want to protect against that? I could
be convinced either way.
--
Ticket he
> Would not a set of routines like:
> BIGNUM* RSA_get0_key_n(RSA *rsa);
> int RSA_set0_key_n(RSA *rsa, BIGNUM *n); (A set for: n, e, d, p, q, idmp1,
> idmq1, iqmp) be much more backward compatible?
We had discussed this in the team, and decided that it was better to have a
single API that took al
Okay, re-open
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4514
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
We use strdup because none of the openssl machinery (error stack, etc) might be
set up yet.
The comment a few lines above says this!
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4489
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubsc
> the 3 'raw128*.dec' should be the same as 'raw128.dat'
> the 2 'raw192*.dec' should be the same as 'raw192.dat'
> and finally, 'raw256-256.dec' should be the same as 'raw256.dat'.
And not surprisingly, all the tests pass :) I will make this work with our
perl-based test framework.
> FYI I wil
> Not necessarily. A union might be more comprehensive.
Better point :)
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4475
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
This looks like a good change.
> This clears what looks to be hundreds of alignment related warnings like
> below.
>
> $ git diff include/openssl/lhash.h
> diff --git a/include/openssl/lhash.h b/include/openssl/lhash.h index
> 2edd738..5da5054 100644
> --- a/include/openssl/lhash.h
> +++ b/includ
> Will the missing export for DHparameters still be fixed for 1.1?
It was:
commit 599eccfcbf8d77eb7c89b6338fdc39a7531a9f82
Author: Rich Salz
Date: Wed Mar 9 20:56:43 2016 -0500
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3676
Please log in as guest with password guest if
> So I guess I should ask... Is using OpenSSL in a C++ program supported
> configuration?
Sure, as much as anything is "supported" in an open source project.
That's not a flip answer.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4473
Please log in as guest with password guest
> The configuration should only be avoided/abandoned due to technical
> reasons, and not philosophical principals.
Lack of resources and interest.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4473
Please log in as guest with password guest if prompted
--
openssl-dev mailing l
> $ make depend && make clean && make
> ...
>
> No rule to make target 'crypto/include/internal/blake2_locl.h'
Shouldn't that be clean ; make depend?
At any rate, yes, some header files moved around. Old dependencies are out of
date ...
--
Ticket here: http://rt.openssl.org/Ticket/Display.
> In order build openssl 1.0.2g
>
> use `make depend` when prompted -- i.e., do NOT ignore the advice
> but DO ignore the 1000's of lines of output, and just proceed to
> subsequent `make`
>
> And that resultant build is considered a reliable build.
>
> Is that correct?
Yes.
--
T
> We're obviously not communicating.
No, sorry.
> 'make clean', without 'make depend' does NOT build.
>
> using 'make depend' BUILDS, but not without 1000's of lines of 'warnings'.
Ignore them. 'make depend' attempts to optimize dependencies so that only
what's needed is built. In this parti
> Here, atm, I've no working path to a 'clean' (warning/error-free) build.
Yes, 'make clean' is just as good as 'make depend'
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4169
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe:
> Otherwise it would not have been possible to encrypt with RC4 with "openssl
> cms -rc4 -encrypt", would it?
It wasn't clear that it was the same version of openssl :)
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4429
Please log in as guest with password guest if prompted
--
Did you enable RC4 when you built openssl?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4429
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Sorry, no, it's too late to get this into 1.1
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4410
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
256 encryption? You mean SHA-256? That's a digest, not encryption.
My guess, without more information like reproducible test, or a packet dump, is
that the client is configured to only use an earlier version of TLS/SSL, which
did not define SHA256 in its crypto-suites.
--
Ticket here: http
We need a little more explanation.
Is this a new feature? Being added to 1.0.2? (That won't be accepted, only
fixes go into released branches.) Or is this something that was dropped and
should be restored?
Unfortunately, the 1.1 freeze deadline is in 24 hours. This won't make it into
1.1 un
> I am a bit confused, as on our server the openssl version is OpenSSL
> 1.0.1e-fips 11 Feb 2013
>
> I am not quite sure why a more recent version of openssl ( 1.0.1p 9 Jul
> 2015 ) does not support sha256.
SHA-256 is in 1.0.1 You said you had issues and asked what to upgrade to, I
gave a r
TS is not a high priority for the OpenSSL team. A month is not a long time.
We are busy right now working on the next release.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4276
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe:
> No, you got that right, NULL being 'safe' to free varies with OS.
Except we mandate ANSI C which means it's portable :)
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https:
> + if (dest->mont_data != NULL)
> + BN_MONT_CTX_free(dest->mont_data);
Free routines don't need to check for non-NULL.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401
Please log in as guest with password guest if prompted
--
openssl-dev mail
Can you make a PR for that? Or just post a diff to objects.txt?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3163
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Roumen, you're right. Does the leak go away when the cleanup_all_ex_data is
called?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2363
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/o
>From discussion in GH 664 with Rob Percival. The issue of repeatd macros came
>up.
Thanks. I've just looked at merging all of the various definitions of those
macros and it's not pretty - not all of the definitions match. There's a bug in
some of the definitions in ssl_locl.h ('c' is not bra
From: Rafał Buczko [mailto:rafal.buczk...@gmail.com]
Sent: Monday, February 22, 2016 8:45 PM
To: openssl-secur...@openssl.org
Subject: [openssl-security] SEGV Fault in the DES_fcrypt
Hi :),
There is a segmentation fault, in function DES_fcrypt (file:
openssl/fcrypt.c:120)
x = ret[0] = ((sa
Still waiting to see from anyone else if it's a non-mac issue.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4290
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> *header = c;
> +header++;
Header isn't used after that assignment. How does this line change anything?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4320
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta
> If you say that removing the #ifdef instead of removing the whole code block
> that it contained was a mistake, then I shall take you at your word and
> refrain
> from harping on *too* much about how naughty it was to have a functional
> change hidden away in a commit which simply entitled itse
Is anyone non a non-Mac seeing this?
I'm beginning to think compiler bug.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4290
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
So now you want to open a PR to fix apps/s_client,server? :)
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2275
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> What is the status of this bug? Will it be fixed in the next release (1.0.2f
> /1.1.0) ?
yes
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4289
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/l
> A correct logic is one single function(the code of check and parse combined)
> that collects the values of extensions and then treat them calls callbacks in
> a
> defined order.
Yes, but right now we've got what we've got :)
> Actually it seems that you could influence the server behavoiur i
> I'm still years away from having enough crypto/C programming experience,
> what in particular should I be working on?
Read the link.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsub
> I said I would be willing to help, but got no reply on how best to ramp up on
> developing a stable addition likely to be accepted by the dev team.
There's no hard-and-fast rules. We recently added some text:
https://openssl.org/community/getting-started.html
But again, for the specific requ
> over 40% of Alexa top 1 million TLS enabled servers enable Camellia
That's different than actual use, as you know.
> I don't see it mentioned anywhere in documentation, especially not in
> ciphers(1) man page. So, is it not so severe, or should the Camellia be
> removed from DEFAULT?
It prob
And update the PR to say that it also closes this ticket :)
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4175
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Doesn't seem that way. Not present on VMS, and I can't find it on MDSN
> either.
So what I'd have to do is downcase the string and do strstr on all lowercase.
Might be reasonable
-
http://rt.openssl.org/Ticket/Displa
> I'm not sure what you think. But all the apps currently only create 1 socket,
> which on some OSes could mean that it's IPv6 (or
> IPv4) only. It needs more work.
Yes, I meant to close the window not the ticket :) Re-opened.
-
I missed a link: https://github.com/openssl/openssl/issues/320
Nobody is pressuring us. I am sure you mean that in a kind and concerned way,
and are not trying to be insulting.
If you can find someone on the openssl-dev team who is willing to take on the
work, then it could go into OpenSSL. O
> That's all we get, a one-liner, no explanation, no rationale, response?
Take a look at some of the discussion here:
https://github.com/openssl/openssl/pull/374
https://github.com/openssl/openssl/pull/154
https://github.com/openssl/openssl/pull/148
I would suggest that i
It’s late and my response was incomplete.
The other part has already landed in master, and that's the "async engine"
support.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
1 - 100 of 205 matches
Mail list logo