I posted a patch and asked if that fixes the issue. Did you not see it?
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
> -Original Message-
> From: The Doctor [mailto:doc...@doctor.nl2k.ab.ca]
> Sent: Monday, January 11, 2016 11:52 AM
> To:
We are considering removing EGD support in 1.1 If your platform still needs
it, please reply soon.
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
___
openssl-dev mailing list
To unsubscribe:
> Not yet Rich.
>
> Please repost.
Steve fixed it already :) So the next snapshot won't fail for this.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> All right, can the above be committed and any other source-backwards-
> compatible behaviour ?
>
> This will help API developers a lot.
It was done and is part of the yesterday's alpha release.
___
openssl-dev mailing list
To unsubscribe:
There are currently three functions related to the EGD:
int RAND_egd(const char *path);
int RAND_egd_bytes(const char *path, int bytes);
int RAND_query_egd_bytes(const char *path, unsigned char *buf, int
bytes);
I would like to just have a single function
Int
Are you sure that your application is built with the same -march, etc., flags
that the library is built with?
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
This is interesting, thanks.
I am not sure how to read the charts; I'm probably being dumb.
I wonder how master compares?
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
___
openssl-dev mailing list
To
Oops, my mistake.
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
> -Original Message-
> From: Rainer Jung [mailto:rainer.j...@kippdata.de]
> Sent: Saturday, January 16, 2016 5:12 AM
> To: openssl-dev@openssl.org
> Subject: Re: [openssl-dev]
> Please note that the patch in RT4247 also contains a hunk for
> crypto/evp/e_camellia.c. This was not committed here, but without it one
> gets the same type of compilation error on SPARC. Since the RT is already
> closed I thought I better ask.
Thanks for catching this. Fixed now.
> What about to remove declaration of FIPS_mode and FIPS_mode_set?
> Those functions could be used by external packages at configure time to
> detect that fips is not supported at all.
> Note 1.0.0 does not declare both functions.
For various reasons, the team wants them there.
Okay, how about this. First, remove the NOTES subhead. Add this to the end of
the first paragraph:
This program does not hash the input data and requires the input data
to be of the proper size, and must not be greater than the size of
the public key field or modulus.
You can't, only someone one the team can. I'll close it.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
This feedback is very useful.
> 1) There is no accessor for the "num" field in the BIO struct.
> This is typically used to store a file descriptor or similar value. As can be
> seen
> by its explicit access in BIO_dup_chain(), there may be legitimate reasons to
> get at its value, even if you
> 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?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> > That sounds like a bug we need to fix. Perhaps something like
> > int BIO_meth_new_index([int flags?])
> But I think even just some advice on _how_ to pick a value here would be
> sufficient. As long as the space is sufficiently sparse, picking a static
> value
> with reasonably low
> 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
> I'm still years away from having enough crypto/C programming experience,
> what in particular should I be working on?
Read the link.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> 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
It's currently "experimental" and we're thinking of dropping it completely from
the next release. If you use it, please reply here soon.
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
--
openssl-dev mailing list
To unsubscribe:
> 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
___
openssl-dev mailing list
To unsubscribe:
> If you see ways in which the code in proposed pull requests is
> unmaintainable, share them.
Nobody on the team is able to take the time to do it.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
My personal opinion is that things like HIGH MEDIUM LOW are bad things ☺
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Larmouth) that a leading zero *is* necessary and required for a positive
> integer when its MSB is one (e.g., 0x80). In other cases it indeed does not
> belong.
Agreed. Perhaps I mis-read your note. Sorry.
--
openssl-dev mailing list
To unsubscribe:
If arbitrary leading zero's were allowed in DER, then the encoding wouldn't be
*distinguished*, i.e., unique.
In BER, almost anything goes :)
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Yes, fixed now.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> If this is not the correct forum to ask this question, can someone please
> point
> me to the right direction.
You might try openssl-users.
> My question is that do I need to write my function to call OpenSSL to use
> OCSP to check if a certificate is revoked or I can configure OpenSSL to
Way cool. Can you send mail to openssl-commits also?
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
> -Original Message-
> From: John Foley [mailto:fol...@cisco.com]
> Sent: Wednesday, January 27, 2016 11:10 AM
> To: openssl-dev@openssl.org
>
> What attack do you have in mind via spreading a cookie good for just one
> source IP address? Sure the botnet can source TFO from that same IP
> address that got the original cookie. Why is that useful?
It's an amplification attack. I don't care about ever getting any reply back.
As I
> Please explain. The traffic can only come from the party who initially
> obtains
> the cookie in a full round-trip. How does the botnet DoS some third party
> with this?
Attacker wants to bring down an akamai host. They connect to one of our
servers with the fast-open option and get the
> This impact all users who upgrade to OpenSSL 1.0.2f and will cause smtpd
> to crash as soon as the RSA engine is used (ie: whenever there's crypto)
It would be interesting to see what they think was wrong.
Our intent is to NOT change API's across letter releases.
But you ARE getting messages. You quoted it below. ☺
Sorry for the flurry of bug activity. We’re cleaning up ticket list.
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
From: Nich Ramsey [mailto:onicr...@gmail.com]
Sent: Monday, February 01, 2016 2:13 PM
To:
Thanks for your patience, and your mailbox's understanding.
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> > It would be interesting to see what they think was wrong.
> >
> > Our intent is to NOT change API's across letter releases.
>
> The only thing I see that's plausibly pertinent is:
Which hardly counts as an API change, does it?
I wonder if we'll see what they found, or an apology?
> new proposed patch:
> https://github.com/openssl/openssl/commit/02c0d44126cf277a8d51b09863fad55daf74
Checked into master; thanks for your help to improve things!
___
openssl-dev mailing list
To unsubscribe:
> Rich, let’s percolate this to the OpenSSL_1_0_2-stable?
Done.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> do you think there are pieces that aren't yet merged? have you tried using
> the common names with 1.0.2 and they don't work?
Nope, I was just reading through all the tickets to do some basic triage.
I will close this one. Thanks !
___
> Take a look at how the commit logs of OpenSSL can be visualised using the
> cool program Gource [1]:
> https://www.youtube.com/watch?v=068ePuZ5OWw
>
> Notice how the Heartbleed (?) bug caused the commit rate and number of
> contributors increases at time 8:10 (May 2014).
>
> [1]
> If we integrate the support natively into OpenSSL, then PKCS#11 URIs (see
> RFC7512) can be first-class citizens throughout the crypto and SSL APIs. Any
> function which takes a filename for a cert or key should also accept¹ a
> PKCS#11 URI.
It'd be great to see a crypto/pkcs11 directory with
> Another point - why OPENSSL_config duplicate name of configuration file?
Because that's the only way we can know that we have to free() it.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
FWIW, I agree with Viktor.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
We recently posted some patches to to our public repo. Since they came out
just before the announced security release, many people have been confused and
thought that perhaps we posted CVE fixes prematurely. This is not the case.
The commit were for fixing low-priority CVE issues, and
> That should work, however we are going to need to distinguish between
>
> Openssl < 1.1 and
>
> Openssl >= 1.1 duing the configuration run.
Looking at openssl/opensslv.h will let you figure it out and then have the
right #ifdef's.
--
openssl-dev mailing list
To unsubscribe:
Roumen, you're right. Does the leak go away when the cleanup_all_ex_data is
called?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
As just about the only team member who trolls through RT and closes things with
any quantity, I am not sure that I agree that fixing a bug requires
documentation if the API isn't already documented.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> I'd like to propose a policy of no bug fixes to undocumented public
> interfaces.
That seems extreme, given how much of the API is undocumented and how much
external stuff depends on private things. I understand the goal. I just want
to make sure you've thought about the proposal. (And
Yes already fixed, thanks.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Please explain why
My guess would be a bug. :)
For these kinds of things, it helps to give the config line you used.
AT any rate, see if this fixes it. Add this line to ssl_utst.c:
static const struct openssl_ssl_test_functions ssl_test_functions = {
ssl_init_wbio_buffer,
> Not for me:
Oh well. That script has way too much perl magic in it for me to try more. :(
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Just a confirmation that this isn't specific to that setup:
> the same happens on OpenBSD (e.g., 5.3) with gcc.
Does something like this fix it?
; g diff util/clean-depend.pl
diff --git a/util/clean-depend.pl b/util/clean-depend.pl
index f29192f..1ace994 100755
--- a/util/clean-depend.pl
+++
> In case its not clear, the difference in the input to clean-depend.pl is that
> when using Solaris cc, /usr/openwin/bin/makedepend is used instead of gcc
Yup, got it. Thanks.
___
openssl-dev mailing list
To unsubscribe:
Try this patch do util/domd
; g diff util/domd
diff --git a/util/domd b/util/domd
index 16de5c7..f0532ad 100755
--- a/util/domd
+++ b/util/domd
@@ -26,12 +26,13 @@ if ${MAKEDEPEND} --version 2>&1 | grep "clang" > /dev/null
||
sed -e '/^# DO NOT DELETE.*/,$d' < Makefile > Makefile.tmp
Yes the script is wrong. Thanks for trying. Working on a real fix :(
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> static BIGNUM bn2, bn768, bn1024, bn1536;
The BIGNUM structure is now opaque. These must be pointers.
> BN_init();
BN_new()
> BN_init();
> BN_init();
> BN_init();
> BN_set_word(, 2);
>
> That's my issue. I cannot get a more recent bind version to stay to stable on
> one box.
Then I think that's going to be a tough issue, and you'll either have to modify
that source or stay at 1.0.2
___
openssl-dev mailing list
To unsubscribe:
Thanks for looking into this.
I don't think it's gonna be on anyone's high priority list to fix in the next
release, so feel free to keep at it :)
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Ø Still, since openssl-1_0_2 does ECDH, and it exposes ECDSA to external
engine(s), how difficult would it be to add ECDH exposure? I suspect - a good
deal easier than getting 1.1 replace 1.0.x as the de-facto deployment standard.
It’s a new feature, so it won’t come from OpenSSL. Don’t know
> The fact that these mechanisms are half-done means to be that it’s a bug in
> need of fixing.
I doubt that anyone else on the team will find this argument compelling.
___
openssl-dev mailing list
To unsubscribe:
Perhaps it's time to level-set. Snapshots are literally snapshots of the daily
tree. There's no expectation that things work, or even compile.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
I don't think you can do this. You will have to have your layer wrap
application data in its own packaging layer. And of course, if there's a TCP
break, you have no idea how many bytes were sent/received on either end.
___
openssl-dev mailing list
TLS does this automatically with its record layer and MAC's. Why do you need
to repeat it?
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Like I said, I don't know that you can do it without changing some source. And
also, heartbeats for TLS (and maybe DTLS) are going away in the next release.
___
openssl-dev mailing list
To unsubscribe:
> Really? Strange. They are recommended for TLS 1.3
No they're not.
Start perhaps at this thread:
https://www.ietf.org/mail-archive/web/tls/current/msg12283.html
___
openssl-dev mailing list
To unsubscribe:
Yes just means an RFC is on the standards track. Not TLS.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> That commit caused EC_PRE_COMP to lose a lot of generality. Was a function
> pointer approach like below considered? I'm not trying to resurrect
> EC_EXTRA_DATA, but a *little* flexibility would be nice.
What functionality was lost that isn't available in the public and standard
EX_DATA model?
> Well I don't see an ex_data attached to EC_GROUP or EC_METHOD.
No, do you need those? We can add them.
> When I look at ec_lib.c, pre_comp_type is only being checked in switch
> statements in _free and _dup style wrappers. Seems out of place and oddly
> specific. Just one dude's opinion :)
TFO is interesting because it lets UDP-style attacks happen at the TCP level.
Normally you can't do a TCP attack unless you have a valid client IP address.
Imagine connecting once and then sending the syncookie to the botnet.
This might be outside the scope of things OpenSSL cares about and I
In OpenSSL 1.1, the fields of most structures are not available, the structures
are made opaque. Instead accessors need to be used; if more need to be
provided, that's an OpenSSL bug. Else it's an openssh porting issue.
--
openssl-dev mailing list
To unsubscribe:
>OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 3 has now
>been made available. For details of changes and known issues see the
>release notes at:
Just to emphasize one important point: Our next release is planned to be
Beta-1, in about a month. After that, no new
> You know, you're entirely right. That's a flaw and needs correction.
> Thanks for the notification.
Yes, the macro's in crypto.h should call through the function pointers.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Can I make a few suggestions?
Wait a day or two and see if the problem is fixed. Snapshots are expected to
be broken now and then.
Posting your config line is very important
./config have-egd
For example. Or whatever it is.
Remove/ignore things that pass, just show what fails.
You should not run 0.9.8, any version. It is old, has known security bugs, and
is end of life.
Go to the website, click on download, and get a recent version.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
A GitHub Pull Request to do this would be very helpful.
We have a month and the team is busy...
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> It looks like we're in fairly good shape for the OpenSSL 1.1.0 release
> to work "out of the box".
That will be great.
> I would like to see what we can do in the way of automated testing,
> though. It should be possible to at least have Travis-CI make
> libcrypto.so for the Linux target,
> *header = c;
> +header++;
Header isn't used after that assignment. How does this line change anything?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Yes, thanks, I was being dumb :(
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> The ssl/t1_enc.c file doesn't compile with '-DTLS_DEBUG':
> Besides, enabling '-DCIPHER_DEBUG', also generates lots of warnings.
Does the attached patch fix it?
diff --git a/ssl/ssl_ciph.c b/ssl/ssl_ciph.c
index 9849185..a9954e9 100644
--- a/ssl/ssl_ciph.c
+++ b/ssl/ssl_ciph.c
@@ -892,7
> OPENSSL_config with NULL argument crash in master branch.
> Please find attached file with proposed patch.
Fixed with commit 4015adf0a3d352cc4013c722f1b2d5374989ac4c; thanks!
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Thanks, fix just pushed to master.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> In both cases I would like to remove these engines from 1.1.0. I'd like to
> hear
> from the community if there is any active use of these. One option if there is
> found to be some small scale use is to spin out the engine into a separately
> managed repo (as has happened recently with the
> Well, it would be a major compatibility break for 1.0.2 and earlier, so no go
> there. As for 1.1.0, folks
Or those who trust us to say what HIGH means should, well, not be lied to.
Something must be changed for 1.1 Either 3DES moves out of HIGH or the
definition of HIGH as documented in
> Now let's not make stuff up:
Caught me, I should have looked it up first. :)
> Since many users enable just HIGH ciphers, they must not exclude the MTI
> ciphers.
Sob. "So let's lie because many users don't know what to do."
--
openssl-dev mailing list
To unsubscribe:
> I used to think that MTI doesn’t mean “Mandatory To Offer”. My codebase must
> have it, but my server (and/or client) configuration may explicitly forbid
> it. Is there anything wrong with this view?
No. At least within the TLS WG this has been brought up multiple times. :)
--
openssl-dev
Conversely, if you do want 3DES set your cipherlist to DEFAULT:3DES
Or someone fix the manpage. :(
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> 3DES is an MTI ciphersuite for TLS, so it must stay HIGH for now.
Say what?
So is RC4 and we don't see that as HIGH. HIGH implies strength, not MTI-ness.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> I'd vote against [catering this information in public header]. As it stands
> now -
> D[BL]_ENDIAN in OpenSSL config lines is actually just an optimization flag,
Okay, you know more about this stuff than I do. I'll leave it to you to help
Dmitry if he needs it :)
--
openssl-dev mailing
> Is the endianess information available in any of installed by the 1.1.0
> version *.h files?
> All the other necessary for building an algorithms-providing engine outside
> of the openssl source tree can be found in the opensslconf.h file.
No, but that's an excellent idea. Which #define do
> with leading 'default' label work correctly?
Yes, the order of case labels doesn't matter. (In fact, it used to be the case
that compilers -- back in the stone age, when they generated code on stone
tablets -- used to be a little more efficient when you did that.)
--
openssl-dev mailing
rsday, February 11, 2016 12:45 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Endianess info
Hello Rich,
On Thu, Feb 11, 2016 at 8:39 PM, Salz, Rich
<rs...@akamai.com<mailto:rs...@akamai.com>> wrote:
> Is the endianess information available in any of installed by the
> What I expect, and was the behavior at least into 2014, is that e.g.
> in ec_lib.c group->foo can happen for members "foo" above that comment,
> but not below that comment. Am I interpreting this wrong?
Not really. But in 1.1 we are doing a great deal of work to make all
structures opaque.
> I'd suggest a patch, which introduces an -attime option (see
> https://github.com/fbroda/openssl/tree/fbroda_ts_date). I'm willing to
> make a pull request if there are no objections.
Please make the PR. And include doc update.
___
openssl-dev
> I am a bit surprised with the following assertion concerning CVE-2016-0798 :
> (Memory leak in SRP database lookups)
> "This issue was discovered on February 23rd 2016..."
Yes, Michel, sorry. You did create a ticket:
https://rt.openssl.org/Ticket/Display.html?id=4172
Thanks for being so
> In the master branch, the best is to look in configdata.pm.
> perlargv => [ "linux-x86_64", "-Wa,--noexecstack" ],
Perhaps configdata.pm should have a comment like
"# configured with ...args...
At the top, to make it stand out?
Or maybe even the command line to reproduce the
> You mean like this?
>
> ./Configure reconf
Yes, but folks are used to seeing it echoed into the config.status file :)
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Would you be able to elaborate why those checks that forbid AEAD were put
> in?
Because it doesn't work. I don't know the details why; probably around setting
the IV or such. But before that the program would just crash.
--
openssl-dev mailing list
To unsubscribe:
> Is there some good reason to not fix make depend? It should also be warning
> free.
No, it should be fixed. Especially since 1.0.2 is an LTS release (for TLS,
henh). But ignoring it's errors is okay until then.
--
openssl-dev mailing list
To unsubscribe:
> Is there any reason why stream ciphers are not supported with CMS?
Go ask CMS folks? :)
> Along the same line, is there any reason why AE(AD) ciphers are not
> supported with “openssl enc”?
A known bug. https://rt.openssl.org/Ticket/Display.html?id=4228 user guess /
pass guest if needed.
> 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
> In particular, how do you know there is not one important warning hiding
> among the thousands of others?
We're talking "make depend"
Not compiling.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Here, atm, I've no working path to a 'clean' (warning/error-free) build.
Yes, 'make clean' is just as good as 'make depend'
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> I would like to point out that there are several already reviewed pull
> requests with new features - e.g. [0] and [1] - waiting to be merged. Do
> openssl devs plan to address these before 1.1 freeze?
>[0] https://github.com/openssl/openssl/pull/576
> [1]
501 - 600 of 1073 matches
Mail list logo
