Some targets need to be removed before rebuilding them:
In apps/Makefile, add $(RM) $@ after progs.h line
In crypt/bn/Makefile, something like this:
bn_prime.h: bn_prime.pl
$(RM) $@
$(PERL) bn_prime.pl $@
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
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
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
If the API requires the same buffer and count, then perhaps the SSL structure
should hold those values, and require the user to send NULL/0 in subsequent
calls?
Or assert(). It's a programming error that requires source changes to fix.
--
Principal Security Engineer
Akamai Technologies,
A colleague here noticed that the pthreads-based locking loses the distinction
between read and write locks. We've collected mutex contention data, and found
that the CRYPTO_ERR lock, used while getting error info, is one of the biggest
offenders.
It turns out that pthreads_locking_callback
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On
Behalf Of Erik Forsberg
What would be the best equivalent yo pthread_once on Windows ?
I was once looking for one, and back then, years ago, I didnt like the
choices.
Perhaps
The Globus syntax is strange. :)
We should support the ISO date/time standard, and use that throughout and not
invent yet another syntax, or yet another flag. It's fairly simple to parse,
and handles timezones, relative times, date/time mixing, and so on. The XML
XSD spec, for example, has a
So I would not understand that we go in a hurry to remove WCE compatibility
I do not think we are in a hurry to do that.
Your patch looks nice. I am CC'ing rt, so that this thread becomes an issue
and we'll see the link to your mail.
--
Principal Security Engineer
Akamai Technologies,
i don't think that's really true. else, why is autoconf friends relying on
a
shell and not perl ? those see way more distribution than openssl.
Last I looked, autoconf doesn't use anything that really wasn't in Version 7
Bourne shell. In my comment, I deliberately used the term posix
These all first appeared in ksh: functions, local, return, $((math))
But to my mind, the question is moot, since post-1.0.2 we'll almost
definitely have c_rehash builtin to the openssl command.
that would also work
:)
It will also be much much much faster, since it doesn't have to call
Fix isn't complete. Adding this message
--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
-Original Message-
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On
Behalf Of Rainer Jung
Sent: Saturday,
Cipher suite names should be case-insenstive: TLSV1 should work as well as
TLSv1.
Not doing this makes valid, but weak, configurations more likely: TLSV1:RC4 for
example.
__
OpenSSL Project
The error makes no sense. The compiler is complaining about the include line?
Do wc -l md2test.c
--
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz
__
OpenSSL Project
Somehow the file that you have is corrupted.
It is not corrupted in the tar file.
It is a local error.
I do not know what the error is but mdtest.c on your disk is WRONG.
__
OpenSSL Project
Yes, I will revert the change.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
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
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.
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
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 want
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 RFC
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,
Yes.
___
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:
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.
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
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.
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:
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
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 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
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.
/
.
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,
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
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
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
(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 allow
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.
Yes,
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
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 an
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.
___
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
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
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
> 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:
> 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
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
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
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
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:
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
> 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
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
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
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
> 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
> 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
> 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
> 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.
> 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.
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
Also see as https://github.com/openssl/openssl/issues/492
___
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
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
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;
-
> 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
> 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
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:
So you're saying just close this ticket?
___
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
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:
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
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
> 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
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
> 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.
> 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.
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:
> 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
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:
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
> 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
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
> 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
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
--
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
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
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
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:
1 - 100 of 198 matches
Mail list logo
