> Unfortunately some platforms can't automatically build the files e.g. WIN32,
> VMS.
Okay, so those targets shouldn't get invoked? Or are you saying that you WANT
the build to fail on those platforms?
> # objects.pl both reads and writes obj_mac.num
> obj_mac.h: objects.pl objects.txt obj_ma
We extract a tarball and make everything read-only. Sometimes an item in the
distribution gets re-made. This can fail because of permissions. So, on
platforms where this would happen, we'd like to remove the file first. I
wasn't advocating to remove them from the distro, I understand we need t
Yes, it predates the latest release. I thin in general it's like a "makefile
hygiene" thing -- if files are read-only, but can be created, then the target
needs to be removed first.
--
Principal Security Engineer
Akamai Technology
Cambridge, MA
_
You might want to read about timing attacks.
--
Principal Security Engineer
Akamai Technology
Cambridge, MA
__
OpenSSL Project http://www.openssl.org
Development Mailing List
I think magic names -- shorthands -- are a very bad idea. They are
point-in-time statements whose meaning evolves, if not erodes, over time.
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openss
> Personally i am willing to put enough trust in the OpenSSL team *even
> insofar* as i now do 'set ssl-protocol="ALL,-VULNERABLE"'
> and leave the task of deciding what is VULNERABLE up to you.
That is not a responsibility we want. No how, no way. It is enough to be
responsible for the code.
--
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz
> You are almost certainly far better qualified to make this decision than most
> administrators.
Not sure who the "you" is. Me, openssl, or the original poster :)
> Nevertheless, if upgrading OpenSSL
> I'd love to see a version of bettercrypto.org that only has to say "to
> configure
> OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE"
That can happen but not by embedding magic strings into code. See
http://rt.openssl.org/Ticket/Display.html?id=3266
ht
> So you want a separate "openssl-conf" package. Fine, then provide it and
> give an easy mechanism for applications to hook into it.
> And for users to be able to overwrite system defaults.
> But this has not that much to do with #3627.
Yes it does. :) A newer simpler API that does what you wa
> For what it's worth, I have tested the Alexa top 1 million servers with the -
> trusted_first option and haven't found a single server that looses its trusted
> status, on the other hand, good few percent of servers do gain it.
It's worth a great deal. Thanks! I love fact-based analysis. :)
> This is a "security issue" in the sense that is a Type-II error (disallowing
> good
> guys). It affects thousands of sites and who-knows-how-many users.
Well, kinda. It disallows good guys who made a mistake and are violating the
RFC. Sure, they're not written in stone and that particular R
Yes.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Matt tried to explain this before.
1.0.1e-30 is not a version that OpenSSL provides. You will have to contact
your vendor.
The backtrace information is not usable as there are no function names; you
will have to build a debugging version.
We cannot help you.
--
Principal Security Engineer,
> I took this a bit further and made TERMIOS the default if nothing else is
> said.
YEA!
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Lets add + to the rules we know are make based.
Isn't that a gnu-make-only thing?
--
Senior Architect, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo
The short answer is that nobody has come up with comprehensive cross-platform
IPv6 support. Fixing the apps isn't enough; how does a server listen on IPv4,
v6, both -- and make it work on our supported platforms? What should the
various BIO API's do?
Looking forward to diff's.
Found during internal code review. V3_alt.c has this proposed change:
ret = X509V3_NAME_from_section(nm, sk, MBSTRING_ASC);
- if (!ret)
+ if (!ret) {
X509_NAME_free(nm);
+ nm = NULL;
+ }
gen->d.dirn = nm;
Kurt points out:
This looks like a bugfix that should probably go to other branches. Bu
In crypto/x509v3/v3_alt.c, around line 603:
- if (!ret)
+ if (!ret) {
X509_NAME_free(nm);
+nm = NULL;
+ }
Kurt points out: This looks like a bugfix that needs to go to other
branches. We probably shouldn't even touch gen in case of an error.
/
.
__
around line 135. The old code has a memory leak, only freeing the BN if
it's NULL.
- if (!group->field)
- BN_free(group->field);
- if (!group->a)
- BN_free(group->a);
- if (!group->b)
- BN_free(group->b);
+ BN_free(group->field);
+ BN_free(group->a);
+ BN_free(group->b);
.
_
void X509_OBJECT_free_contents(X509_OBJECT *a)
{
+ if (!a)
+ return;
switch (a->type) {
already done in master.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Need
"if (!param) return;"
at the start of X509_VERIFY_PARAM_free
Found by Kurt while code-reviewing some of my changes on master.
.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
around line 218 add the if check:
static void cleanup(X509_OBJECT *a)
{
+ if (!a)
+return;
.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Around line 2226 add the NULL check.
void X509_STORE_CTX_free(X509_STORE_CTX *ctx)
{
+ if (!ctx)
+ return;
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
need to add these lines around 115 in cma.c
void CMAC_CTX_free(CMAC_CTX *ctx)
{
+if (!ctx)
+return;
CMAC_CTX_cleanup(ctx);
OPENSSL_free(ctx);
}
.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listi
> My suggestion is, at least for 1.1 (but I don't see why this can't be ported
> down to 1.0.2 and 1.0.1) remove the config loading code from
> openssl.c:main() and add the same code in req.c as you can find in ts.c or
> srp.c... possibly refactoring that code into a helper function in apps.c.
Ye
> > (Documentation is in the source files, not a .pod)
>
> Do you have code to produce usable manpages from the embedded
> documentation? We can't ask users to read the source.
I believe Todd meant for the test program.
> * The copyright notice does not refer to any license that would all
Generally, these look good. I have concerns about three (that you raised);
quoting from your README. Any comments from others?
+ err.c.patch
The 'int_thread_del_item' function calls 'int_thread_release' that accesses
(*hash), but this is invalid because 'int_thread_del_item' frees
'int_threa
>Blake2s is 256-bit, while Blake2d is 512-bit. These are the ones I assume
>that would be best for addition. The other two, Blake2sp and Blake2bp are
>multi-threaded, and are optimized for multi-core CPUs.
It is unfortunate that 's' and 'd' mean different algorithms, while 2sp and 2bp
are, pr
So it's really a request to add four hash functions. Bummer.
> In practice the parallel mode works nicely on modern systems.
Well, on clients. On servers, presumably, those cores would be busy ;)
I'd support adding 2b and 2s, in spite of the fact that the names are really
really bad. I'm les
This is great!
Any chance you can run it against master? I'm hoping most of the ones in apps
go away ...
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
This is strange, since OpenSSL doesn't use "gethostname" which the comments
mention. Can you add the exact error message?
And why only that one file? More strangeness.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listi
Ah, that explains my confusion; I was looking at master. So we need to make
this fix for 1.0.x Thanks.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
How about 256 on the stack?
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
The first place to look is to see if your program has any pointers errors that
are overwriting memory.
Try something like valgrind or ASAN.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
It seems that the simplest and most obvious thing is to indicate that you don't
care about the dates, which is what this patch does.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> If requested, I can still provide a patch with the alternative variant of
> using a
> X509_V_FLAG_NO_CHECK_TIME flag if that's considered better than using a
> 'special' time of (time_t)-1 with X509_VERIFY_PARAM_set_time().
Yes, please.
___
openss
My feeling is that you should not be copying an EVP if data is NULL and that
the earlier null checks are erroneous. But I could be wrong.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Yes. But skimping on security features is not a good way to deal with
> software/firmware bloat. And again, attacks on this layer are increasing in
> quantity and sophistication. The current protection mechanisms appear
> insufficient. Draw your own conclusions.
But this isn't a general-purpose
> May I ask one question: Why?
Excellent question. "Because there is an RFC" is not a good enough reason any
more, I think.
> Does camellia offer any significant advantage in
> any situation that would justify increasing support?
Yes, I'd like to know who needs it.
GOST is going to move to a
A non-matching kdf_type moves from return 1 to return 0 if NO_CMS compiles out
the KDF_X9_42 change - that is a different error return and that seems
incorrect to be making that change as part of handling conditional compilation
additions.
Although it looks like that change is one that should be
> so will v1.1 be released in this year?
More likely early 2016.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Please do "grep rehash Makefile" at the toplevel.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Yes, it has two main functions, based on #ifdef unix.
Not sure why netBSD doesn't -Dunix.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Hmmm. It used to build and test OK, did the check for -Dunix change
> recently?
No.
> Is the -Dunix test in config script?
No, it's in apps/rehash.c
> For a quick fix I added -Dunix to CFLAGS in Makefile and I am able to make
> and run tests.
Sounds like the netBSD config needs to add that.
Since email re-opens the ticket, let's use this one :)
What's the output of this command:
HARNESS_VERBOSE=yes make 'TESTS=test_rehash' test
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> YES! It's a one user box that I regularly update and install on, so rarely
> run as
> reduced/un-privileged user.
>
> If I switch to non-root, this passes.
Glad we got it figured out. Perhaps we can add a warning to the test (running
as root, expect to fail) or some such.
> if so, any plan to backport it?
No, it's a new feature; only fixes go into releases.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> I want to know how it's going with the ticket [openssl.org #4060]?
Nobody's looked at it yet.
You need to include a backtrace. And a way to reproduce it (sample code)
before anyone will really be interested.
___
openssl-dev mailing list
To unsubsc
> If things like BIO_new_file() were inline, or macros, then the compiler could
> *see* that they'd return NULL. And lots of code in the *calling* functions
> (basically everything but the error path) could be elided from the compiled
> result...
Cool, will do that.
_
> OPENSSL_stderr() is such thing. Well, for a Unix person it's really
> meaningless
> function, but it was introduced to solve small but irritating problem in FIPS
> module context on Windows.
I removed it :)
Since 1.1 doesn't support FIPS, that's okay. But we'll have something like
that for
> If you want to keep it can we make it return a BIO? Many platforms could use
> it then for serial debug output etc.
That's what I'm going to do.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Also, note that the earliest this could happen is for 1.1 (it's a new feature),
and it's not high on our priority list for that release right now. Patches
that are regularly rebased against master would help.
___
openssl-dev mailing list
To unsubscri
More information is needed. But this is most likely not an OpenSSL bug, it's
the FIPS setup-testing.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> AFAICT if SSL_read returns between the first handshake and the second, you
> don't get the problem.
I think it should not matter when or what SSL_read returns. That should only
be returning application-level data to the caller. All state manipulations,
etc., should be done underneath and com
Yes, the various no-options don't work well. Not a high priority for 1.0.2
unless patches are provided.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> PACKET_buf_init. This code can assume that |len| is from a trusted source.
>
> The purpose of the sanity check is not then for security, but to guard against
> programmer error. For a correctly functioning program this test should never
> fail.
I would say that the combination of these two thi
> I am trying figure out valgrind report leak. in openssl 1.0.1c.
You don't have enough of the backtrace for us to reproduce it. Please add a
simple demo program.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/op
We have another internal cleanup in-progress that will fix this in a different
way.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Also see as https://github.com/openssl/openssl/issues/492
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
I think that instead of the #ifdef being removed, the if() test should be
removed.
This was my mistake.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Should we support no-nextproto?
The #ifdef's complicate the code, and the implementation is very small.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
This is good. I changed it to size_t and will merge it as part of other
"secmem" API cleanups I have in progress.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
I don't know that I would call it a regression, but rather a difference. :)
I'll fix the summary but not the old uncommon behavior.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
I fixed that, added docs. It's in code review now. Thanks!
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
This link is the right one, we'll fix the code, thanks:
https://www.openssl.org/community/index.html#bugs
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Yes we would be interested in this but someone would almost definitely have to
be provided as a complete patch because it seems unlikely anyone on the team
will get around to doing it by 1.1 release.
___
openssl-dev mailing list
To unsubscribe: https:
Does this diff fix it?
; g diff apps/engine.c
diff --git a/apps/engine.c b/apps/engine.c
index c373df5..3c0ff96 100644
--- a/apps/engine.c
+++ b/apps/engine.c
@@ -312,12 +312,17 @@ int engine_main(int argc, char **argv)
BIO *out;
const char *indent = " ";
OPTION_CHOICE o;
-ch
Please see this:
https://github.com/openssl/openssl/compare/master...richsalz:rt4194?expand=1
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Tweaked, sigh.
; ./util/opensslwrap.sh engine - dynamic -pre
engine: Cannot mix flags and engine names.
engine: Use -help for summary.
exit 1
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-
So you're saying just close this ticket?
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
The old style of complete intermix of flags and parameters is not going to
happen.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
There is a fix for this that is in the internal code-review phase. It's based
on patches Roumen sent.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> SSLKEYLOGFILE env var is a good current standard, so I think openssl should
> use it as well.
Patches to implement all of this would be helpful, otherwise it will probably
not make it into the next relese.
___
openssl-dev mailing list
To unsubscrib
> Any idea when these will be in github?
Hopefully in time for the next alpha 1.1 release, in a week or two.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> I have implemented it as a small part of my Master thesis, maybe I could
> polish it and submit a PR.
Please do this.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> I am a bit worried when I see C-beginner mistakes like this in a security
> suite:
> When using sscanf on data you have not produced yourself, you should
> always assume they will be bigger that your largest buffer/variable and deal
> correctly with that.
That's a bit of an exaggeration here.
And also opt_int and opt_long in apps/opt.c are useful.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> The worry is not about this particular case (where it does not seem to be
> possible to abuse), but as a general observation: If the rest of the code has
> the same quality, then we will be screwed.
Shrug. We do the best we can. We try to do a good job. Almost everyone would
agree that the
> May I suggest the bug also becomes a wish for support for > 2GB numbers,
> as that is what the user originally wanted?
Unlikely to happen in 1.1 because of portability issues.
Call it multiple times or, better, write a small program to generate a PRNG
stream.
The output of encryption is not a string, it is an array of binary bytes.
I don't think there is a bug here.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Are you sure that your application is built with the same -march, etc., flags
that the library is built with?
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
__
There is something unusual in your local environment.
; cat a.c
#include
#include
#include
int main()
{
char code[64]={0};
char outbuffer[64];
int codelen = sizeof (code);
RC4_KEY rc4_key;
strcpy(code,"This is secrect");
RC4_set_key(&rc4_key,7,(unsigned char *)"zenraoli"
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
e_os.2 line 327::
# if !defined(inline) && !defined(__cplusplus)
Should this be:
# if !defined(ossl_inline) && !defined(__cplusplus)
The purpose of this section is to end up with a good definition for ossl_inline
If some preceding header file (and I have run across this) does a #define
> 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.
Yes, the 1.1.0 release will have ipv6 support (down at the BIO layer).
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
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 k
> This suggests that you have on-path capabilities between each of the
> reflectors and the victim, right?
I don't think so: you need the first attacker to get the cookie, then you
spread it out.
> If you have on-path capabilities, couldn't you do a similar attack against a
> live
> TCP sess
I closed the first ticket, so everything is okay.
If you want to do GitHub pull requests and just open an RT to refer to that,
that is also okay.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> I’m running OS X 10.11.3 and OpenSSL 1.0.206
I cannot reproduce this. Did you build from source, or is that a
vendor-provided version? The ".206" isn't part of our release naming. Did you
mean 1.0.2f? Do you have a sample program to show the error?
___
> The diff works perfectly on master, but exposed a new bug (bare snprintf).
> The following patch fixes it. I can make a PR (or add it to my existing PR
> #512)
> if you'd like.
Please do as a separate PR. Thanks.
___
openssl-dev mailing list
To un
> 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 !
___
openssl-de
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
> 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
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
> 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.
-
> 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
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
> 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
> 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
901 - 1000 of 1133 matches
Mail list logo
