Sorry no, I have managed to stay away from perl so understand nothing
of its wonders.
regards
On 2 July 2014 04:47, Rich Salz via RT r...@openssl.org wrote:
So one possibility is Pod::DocBook. Do you have a feel for how good it is?
Right now, OpenSSL only depends on Perl. It would probably be
Hi,
Ok, thanks for the reply.
Regards,
Manjesh.
On Tue, Jul 1, 2014 at 10:01 PM, Matt Caswell via RT r...@openssl.org wrote:
I can confirm that CVE-2014-0198 is fixed in OpenSSL-1.0.1h.
Setting this ticket to resolved.
Matt
--
Regards,
Manjesh.
ควยไง สัด
Date: Tue, 1 Jul 2014 16:57:59 -0400
From: ty...@mit.edu
To: openssl-dev@openssl.org
Subject: Re: Makedepend bug?
On Tue, Jul 01, 2014 at 02:10:31PM -0400, Mike Bland wrote:
I was wondering why 'make depend' output was saved in the Makefiles.
So I guess adding the .d files to
เหี้ยไร เนี่ย
Date: Tue, 1 Jul 2014 21:14:13 +0200
From: janpo...@gmx.net
To: openssl-dev@openssl.org
Subject: Small website bug
if you go to About, then to Contacts, Credits or Roadmap, there
is no General link only Gerneral text
Jan
On 07/01/2014 11:50 AM, Ben Laurie wrote:
Our soon-to-be-released roadmap has this to say on supported platform:
* Currency, i.e. a platform is widely deployed and in current use
* Vendor support
* Available to the dev team, i.e. the dev team have access to a
suitable environment in which to
On 2 July 2014 13:33, Florian Weimer fwei...@redhat.com wrote:
On 07/01/2014 11:50 AM, Ben Laurie wrote:
Our soon-to-be-released roadmap has this to say on supported platform:
* Currency, i.e. a platform is widely deployed and in current use
* Vendor support
* Available to the dev team,
On Tue, Jul 1, 2014 at 7:14 AM, Jeff Trawick traw...@gmail.com wrote:
On Mon, Jun 30, 2014 at 5:14 PM, dcrue...@qualitesys.com wrote:
Hello
openssl-SNAP-20140630
make ko
in apps/speed.c:318:4
warning: format '%d' expects argument of type 'init', but
argument 3 has type
On Mon Mar 24 23:02:59 2014, truer...@sea.plala.or.jp wrote:
Hi, everyone.
openssl ts -reply ... command always uses SHA-1 for signing.
This patch can specify the messege digest algorithm for signing;
openssl ts -reply -queryfile req.bin -config tsa.cnf -sha256 resp.bin
Please merge it.
On Wed Jul 02 07:12:19 2014, noloa...@gmail.com wrote:
Questions on AES-NI and how to enable them have come up twice recently
on the stack exchanges (like stack overflow).
This patch documents use of the AES-NI instruction by way of the EVP_*
interface.
Since this may in future cover much
The toplevel Makefile runs the POD pages threw a sed script that remove the (n)
notation.
This seems to address the concerns.
POD, and POD2MAN and POD2HTML are a bit arcane for me.
__
OpenSSL Project
On 07/02/2014 02:44 PM, Matt Caswell wrote:
I strongly suggest to add 8 bit chars and 32 bit ints as an additional
requirement. There is some idea that 16-bit platforms (such as MS-DOS or
Windows prior to the Win32 API) are still supported, but this is clearly not
the case because a lot of
Hi guys,
I'm very happy to see the OpenSSL roadmap.
However, I feel that the developer group is a bit closed
to outsiders.
I requested access to the OpenSSL scan results on coverity,
and up to now, my request is still pending :-(
--
This message is strictly personal and the opinions
However, I feel that the developer group is a bit closed to outsiders.
More communication and transparency is coming, as we have a bigger and more
invigorated developer team. It will take time. But not everything will always
be discussed in public mailing lists right away, parciularly
Discovered this problem while trying to fix
https://github.com/joyent/node/issues/7704.
Attached is a fix for it.
Trouble is that modified code might avoid crash, but it doesn't produce
correct result either. [No, not even Adam's suggestion]. Actually
bn_mul_mont is abused in bn_exp.c,
On Wed, Jul 2, 2014 at 9:48 PM, Salz, Rich rs...@akamai.com wrote:
However, I feel that the developer group is a bit closed to outsiders.
More communication and transparency is coming, as we have a bigger and more
invigorated developer team. It will take time. But not everything will
Andy,
I'd still pull Adam's changes, at least for consistency reasons. Other
assembly files seems to be using signed comparison for the same kinds of
operations.
What do you think about it?
Cheers,
Fedor.
On Wed, Jul 2, 2014 at 9:54 PM, Andy Polyakov via RT r...@openssl.org wrote:
Andy,
I'd still pull Adam's changes, at least for consistency reasons. Other
assembly files seems to be using signed comparison for the same kinds of
operations.
What do you think about it?
Cheers,
Fedor.
On Wed, Jul 2, 2014 at 9:54 PM, Andy Polyakov via RT r...@openssl.org wrote:
I write fixes for pieces of software that I depend on. Some time ago, I sent
a
diff for OpenSSL.
Great, thanks.
If I'm interested in fixing OpenSSL, why shouldn't I have access to coverity
scans ?
Other Open Source projects have provided me access to their coverity scans,
despite the
Whew, that was a lot of work.
Fix will be committed to master branch shortly.
Many, usually -engine, were already added.
But many weren't. Thanks!
I only added the ones you found were missing.
I am sure many new options are still missing :(
I have cleaned the patch from unnecessary whitespace changes.
Kind regards, Jaroslav
ts_signing_digest_cleaned.patch
Description: Binary data
smime.p7s
Description: S/MIME cryptographic signature
On Wed, Jul 2, 2014 at 11:23 AM, Loganaden Velvindron
logana...@gmail.com wrote:
If I'm interested in fixing OpenSSL, why shouldn't I have access to
coverity scans ?
I'm not a committer, and not a core member, but I am fully prepared to
answer your question. Because the policy of the project
I looked at all BIO_read calls in ssl/*.c and it appears the check is for =0
now, not 0.
So we fixed the code to conform to the doc. :)
__
OpenSSL Project http://www.openssl.org
Development Mailing
Hi folks,
I know the following patches will cause a controversy just like the
issues they resolve caused me and several other people headaches when
debugging them.
But first things first. The attached patches (intentionally) do the
following two things:
1. Adjust the limit for maximum allowed
Added some text to the last paragraph:
When using i2d_SSL_SESSION(), the memory location pointed to by pp must
be large enough to hold the binary representation of the session. There
is no known limit on the size of the created ASN1 representation, so
the necessary amount of space should be
I'd still pull Adam's changes, at least for consistency reasons. Other
assembly files seems to be using signed comparison for the same kinds of
operations.
What do you think about it?
I think it's appropriate to harmonize branches with interface. But it
takes deal of concentration and
I took the first part of the diff, adding this:
+Note that PKCS #1 adds meta-data, placing limits on the size of the
+key that can be used.
+See LRSA_private_encrypt(3)|RSA_private_encrypt(3) for lower-level
+operations.
__
I have managed to stay away from perl so understand nothing of its wonders.
what a great turn of phrase.
we're thinking about the doc format, but for now... no.
__
OpenSSL Project
Since BIO_push(a,b) returns a, I changed the code examples to ignore the return
value
and explicitly used b64 Perhaps I should have introduced a new BIO* top and
used that?
If so open/re-open a ticket.
__
OpenSSL Project
Hello Steve,
I have posted similar patch 4 years ago - please take a look at #2145. It
contains also accessor function, documentation updates, digest algorithm can
be specified in the configuration file etc. I will apply the flags technique
you have mentioned and will post the update. Can you
I'm totally willing to cooperate on this, and may have enough skills to do
it.
Do you think it could be possible for us to collaborate on this topic?
Thank you,
Fedor.
On Wed, Jul 2, 2014 at 11:08 PM, Andy Polyakov via RT r...@openssl.org
wrote:
I'd still pull Adam's changes, at least for
I'm totally willing to cooperate on this, and may have enough skills to do
it.
Do you think it could be possible for us to collaborate on this topic?
Thank you,
Fedor.
On Wed, Jul 2, 2014 at 11:08 PM, Andy Polyakov via RT r...@openssl.org
wrote:
I'd still pull Adam's changes, at least for
Man, which crazed individual implemented that magical -spkac output stuff?
anyhow, thanks, issue resolved.
Hopefully the next Sherlock episodes won't take so long to appear :)
__
OpenSSL Project
Remove the reference from err.pod; thanks.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
based on spell(1) output.
diff --git a/doc/ssl/SSL_CONF_CTX_set_ssl_ctx.pod
b/doc/ssl/SSL_CONF_CTX_set_ssl_ctx.pod
index 4fc8f06..2049a53 100644
--- a/doc/ssl/SSL_CONF_CTX_set_ssl_ctx.pod
+++ b/doc/ssl/SSL_CONF_CTX_set_ssl_ctx.pod
@@ -14,12 +14,12 @@ SSL_CONF_CTX_set_ssl_ctx,
Someone fixed this awhile ago.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
RSA_generate_key_ex is in RSA_generate_key.pod
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
I'm totally willing to cooperate on this, and may have enough skills to do
it.
Do you think it could be possible for us to collaborate on this topic?
Sure! I'd appreciate it. Start by preparing patch harmonizing branches
with interface. Still I can't promise swift review and reply, so please
On Wed Jul 02 21:31:19 2014, jaroslav.imr...@disig.sk wrote:
Hello Steve,
I have posted similar patch 4 years ago - please take a look at #2145. It
contains also accessor function, documentation updates, digest algorithm can
be specified in the configuration file etc. I will apply the flags
On Wed Jul 02 20:48:55 2014, jaroslav.imr...@disig.sk wrote:
I have cleaned the patch from unnecessary whitespace changes.
Thanks. I can see that you added a new field in the middle of a structures. For
binary compatibiity reasons new fields can only go at the end of structures.
Steve.
--
Dr
As for what to do. As far as I recall the tangible reason for redefine was
that [by 1300 time] definition depended on compiler command line options (or
wasn't a call to function). If definition does not depend on command line
*now*,
*and* always resort to function call, then it would be
According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.
__
OpenSSL Project http://www.openssl.org
Development Mailing
Can you send the C# file? It might be of interest.
Not making any commitment, just want to look. Thanks.
__
OpenSSL Project http://www.openssl.org
Development Mailing List
Looks like fixed in the latest (2013) version; there is no cross-comipled
entry.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Fix will be checked in to master shortly; thanks.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
To be commit'ed to head shortly, thanks.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
I'm on the OpenSSL_1_0_2-stable branch, commit d85a772, and compilation
fails for darwin64-x86_64-cc with the error reported at the bottom. The
commit that introduced the compilation issue is
70fddbe32a7b3400a6ad0a9265f2c0ed72988d27.
If instructed, I can try to help by running more tests.
Fixed, thanks.
Opened a new ticket because verify -help is kinda lousy.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated
The verify -help output is non-standard (rest of them are a set of lines, one
per flag).
__
OpenSSL Project http://www.openssl.org
Development Mailing List
they're equivalent; I believe -bugs is aliased to rt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
Someone contributed SSL_CTX_set_tlsext_ticket_key_cb documentation. But there
are magic numbers,
16, in it. The source he based the doc on has the same magic numbers, which is
good. But the fact that
they just appear there -- are they fixed values? -- is not so good.
We need to look at the code
Wow, thanks for writing that. And especially the long example.
It points out various magic numbers; see RT ticket 3420 about that.
To be submitted to master head shortly.
__
OpenSSL Project
Simple fix, thanks.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
You are right the default is 100 not nine.
Thanks.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
Integrated, thanks.
Will be put on main/master shortly.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
Fixed by someone sometime.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
Someone already fixed it, and updated the sample code to use the right API.
Good for that nameless person.
__
OpenSSL Project http://www.openssl.org
Development Mailing List
Fixed the typo, thanks.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
Thanks, fixed, to be commit'd shortly. (The update, not me :)
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
Fixed, added -servername to the pod file.
Thanks.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
The failures will not be dependent on the input stream.
It could be allocation failures, for example.
But very unlikely.
__
OpenSSL Project http://www.openssl.org
Development Mailing List
Since this may in future cover much more than just AES-NI...
Good observation Doctor, done. Attached is the updated text.
diff --git a/doc/crypto/EVP_EncryptInit.pod b/doc/crypto/EVP_EncryptInit.pod
index f6e4396..8d7636c 100644
--- a/doc/crypto/EVP_EncryptInit.pod
+++
I agree. Not all open source projects play a major role in securing much of
the worlds e commerce.
On Jul 2, 2014 2:52 PM, Michael Sierchio ku...@tenebras.com wrote:
On Wed, Jul 2, 2014 at 11:23 AM, Loganaden Velvindron
logana...@gmail.com wrote:
If I'm interested in fixing OpenSSL, why
Thank you for the comment - I have moved the new field at the end of the
TS_RESP_CTX structure.
I have also introduced TS_SIGNING_DIGEST flag that should prevent binary
compatibility issues when application allocates TS_RESP_CTX itself using older
headers but uses a newer library - you have
Thanks. All fixes checked into master.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
This was tricky for me through; nice detective work!
The text is now
EVP_EncryptFinal(), EVP_DecryptFinal() and EVP_CipherFinal() are
identical to EVP_EncryptFinal_ex(), EVP_DecryptFinal_ex() and
EVP_CipherFinal_ex(). In previous releases they also cleaned up
the Bctx, but this is no longer done
Removed the outdated reference, thanks.
538860a..f111298 master - master
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated
66 matches
Mail list logo