> On Jan 21, 2016, at 2:45 AM, Erik Forsberg wrote:
>
> 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 -M
>
> Still, considering that, the problem is elsewhere, as I tried
> various styl
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 -M
Still, considering that, the problem is elsewhere, as I tried
various styles of input and could not see any correlation
>-- Original Message
No, doesnt help.
Still no valid dependencies.
The warnings can of course be silenced by inserting a
no warnings "uninitialized";
but that doesnt fix the absence if valid dependencies in the generated Makefile
>-- Original Message --
>
>
>> Just a confirmation that this isn't specific to that set
> 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
On Thu, Jan 21, 2016, Salz, Rich wrote:
> --- a/util/clean-depend.pl
> -while() {
> -my ($dummy, $file,$deps)=/^((.*):)? (.*)$/;
> +while(my $line = ) {
> +while ($line =~ /\\$/) { chop($line); chop($line); $line .= ; }
> +my ($dummy, $file,$deps)=$line =~ m/^((.*):)? (.*)$/;
Not for
> 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
+++
On Wed, Jan 20, 2016, Erik Forsberg wrote:
> seems util/clean-depend.pl is now broken if using Solaris cc compiler.
Just a confirmation that this isn't specific to that setup:
the same happens on OpenBSD (e.g., 5.3) with gcc.
> I get gazillions of 'Use of uninitialized variable in ' when run
seems util/clean-depend.pl is now broken if using Solaris cc compiler.
Looks like its working if gcc is used, the difference seems to be that if
gcc is used the input to clean-depend.pl looks like
object.o: dep1.h dep2.h \
dep3.h dep4.h
if Solaris cc is used it looks like
object.o: dep1.h
obje
X509_REQ_sign, X509_sign and similar functions return the signature length
instead '1' as documented.
Justification:
Both function return whatever ASN1_item_sign returns:
https://github.com/openssl/openssl/blob/master/crypto/x509/x_all.c#L95
https://github.com/openssl/openssl/blob/master/crypto/x5
I vote "for" :) Let me know what should I do if openssl will decide to move
forward
Regards,
Alex.
On Wed, Jan 20, 2016 at 1:35 PM, Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:
> On 1/20/16, 16:25 , "openssl-dev on behalf of Salz, Rich"
> wrote:
>
> >> The fact that these mechanisms
On Wed, Jan 20, 2016 at 06:11:16PM +, Salz, Rich wrote:
> > 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
>
Source modificatio
On 1/20/16, 16:25 , "openssl-dev on behalf of Salz, Rich"
wrote:
>> 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.
I don’t know. “pkeyutl -engine pkcs11 -keyform engine -der
> 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: https://mta.openssl.org/mailman/listinf
> Ø 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.
Ø 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
On Wed, Jan 20, 2016 at 11:34 AM, Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:
> Probably it was one of the main reasons why we didn't use pkcs11 for
> ATECC508A and wrote an engine instead
>
>
> I still argue with the approach (IMHO nobody needs yet another limited
> engine
>
Limited?
On Wed, Jan 20, 2016 at 12:19 PM, Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:
> Very possible that I'm missing the point here.
>
> 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
Very possible that I'm missing the point here.
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.
Plus, by this time
Hello -
I ran OpenSSL v1.0.2e through static analysis (Cppcheck v1.62) and there was
one apparent memory leak identified as follows:
openssl-1.0.2e\ssl\kssl.c error line: 2234 Memory leak: p_data (new_p is
freed in the error return condition, but its data field references a buffer
addres
Hi all
When an IPv6 address:port tuple is given to s_client's -connect option,
the internal parsing of the address/port seems to fail. The port is
taken to be a part of the IP address, and the IP address is shortened by
the first 2 bytes:
# openssl s_client -connect 2a00:c38:10a::1:0:71:443
getse
You are missing the point. OpenSSL-1.0.2 only exposed ECDSA, not
ECDH to external engines. It took years to even get ECDSA exposed.
OpenSSL approach to support this is OpenSSL-1.1 that does a lot of
other things. But that was there approach. Its their package.
From
Yes. The exposure of the ECDH hooks is provided by OpenSSL-1.1.
Openssl-1.0.2 does not have the needed code.
On 1/20/2016 1:10 PM, Blumenthal, Uri -
0553 - MITLL wrote:
Are you saying
it won't work on OpenSSL_1_0_2-stable?!
> Probably it was one of the main reasons why we didn't use pkcs11 for ATECC508A
> and wrote an engine instead
I still argue with the approach (IMHO nobody needs yet another limited
engine), but constraining ECC additions to 1.1 does not make any sense to
me. 1.0.2 is going to be around for a quit
Probably it was one of the main reasons why we didn't use pkcs11 for
ATECC508A and wrote an engine instead
Regards,
Alex.
On Wed, Jan 20, 2016 at 11:10 AM, Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:
> Are you saying it won't work on OpenSSL_1_0_2-stable?!
>
>
> Sent from my BlackBe
On Wed, Jan 20, 2016 at 9:46 AM, Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:
> The ATECC508A is a chip. There are few USB devices built by Atmel on its
> base. Or you can use the chip directly over I2C (that many people like to
> do). You can follow the links that we posted on the ATE
Are you saying it won't work on OpenSSL_1_0_2-stable?!
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: Douglas E Engert
Sent: Wednesday, January 20, 2016 14:07
To: openssl-dev@openssl.org
Reply To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] ECDH engine
Patches are underdevelopment for OpenSC's libp11 and engine_pkcs11
to support ECDH. There are waiting for OpenSSL-1.1 to be come stable
and some minor bug fixes. Testing is proceeding using
OpenSSL-1.1-pre2 today. OpenSSL-1.1 is needed because it exposes
the functions n
On Wed, Jan 20, 2016 at 11:05:58AM -0700, The Doctor wrote:
> > The bind code is what needs to be adjusted, given that openssl 1.1 is
> > intentionally introducing API changes and removing direct access to many
> > structures. It seems quite unlikely that an EoL version of a
> > third-party softw
> 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: https:
On Wed, Jan 20, 2016 at 02:43:48AM +, Salz, Rich wrote:
>
> > static BIGNUM bn2, bn768, bn1024, bn1536;
>
> The BIGNUM structure is now opaque. These must be pointers.
>
> > BN_init(&bn2);
>
> BN_new()
>
> > BN_init(&bn768);
> > BN_init(&bn1
On Tue, Jan 19, 2016 at 08:53:49PM -0600, Benjamin Kaduk wrote:
> On 01/19/2016 05:37 PM, The Doctor wrote:
> > Tried to compile an old bind and ran into
>
> Why?
>
> > What needs to be adjusted?
> >
> >
>
> The bind code is what needs to be adjusted, given that openssl 1.1 is
> intentionally in
I forgot to add that OpenSSL-1_0-2-stable with the current (Github master)
engine-pkcs11, libp11, and OpenSC successfully does ECDSA with keys on the
token (tested for ECC256 and ECC384).
OpenSC tools successfully derive (i.e., implement ECDH1_DERIVE). I'm waiting
for libp11 and engine_pkcs11
> The ATECC508A is a chip. There are few USB devices built by Atmel on its base.
> Or you can use the chip directly over I2C (that many people like to do). You
> can follow the links that we posted on the ATECCX08 Engine repository WiKi to
> learn about the chip.
I see, thanks.
> Well, our first
Hi Uri,
The ATECC508A is a chip. There are few USB devices built by Atmel on its base.
Or you can use the chip directly over I2C (that many people like to do). You
can follow the links that we posted on the ATECCX08 Engine repository WiKi to
learn about the chip.
Well, our first indent was to
I see. Steve, what would you suggest to add to the man page, in view of
what we’ve been discussing for the last few days here?
--
Regards,
Uri Blumenthal
On 1/20/16, 11:37 , "openssl-dev on behalf of Dr. Stephen Henson"
wrote:
>On Wed, Jan 20, 2016, Blumenthal, Uri - 0553 - MITLL wrote:
>
>
On Wed, Jan 20, 2016, Blumenthal, Uri - 0553 - MITLL wrote:
> On 1/20/16, 5:10 , "Hubert Kario" wrote:
>
> It appears to me that pkeyutl is more an instrument to access those
> primitive operations, unlike dgst that provides access to the ???true???
> (complete) signature function that includes
What is this Atmel x508x? Is it a chip? Is it a token/smartcard? Is it
accessible via PKCS#11 at all? Is it accessible by/via OpenSC?
I am trying to figure why such a generic and useful set of ECC operations
(Sign, Derive) is implementation-limited to one single .
A much better solution to me
Hi Steve,
And here is the ENGINE implementation for Atmel ATECC508A with few small
patches to OpenSSL_1_0_2-stable:
https://github.com/AtmelCSO/cryptoauth-openssl-engine
Your comments are welcome.
Regards,
Alex.
On Sat, Dec 19, 2015 at 12:49 PM, Dr. Stephen Henson
wrote:
> On Fri, Dec 18, 201
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
Gisle Vanem wrote:
> And adding other options show additional leaks.
> E.g. '-nbio_test -reconnect' results in 12 leaks:
>
> [12:15:17] 13704 file=crypto/bio/bio_lib.c, line=68, thread=4248,
> number=72, address=0x2ccf468
> [12:15:15] 13016 file=crypto/bio/bio_lib.c, line=68, thread=4248,
>
https://github.com/openssl/openssl/pull/571
I was getting errors for curves with even order. This patch squelches
the errors.
139858767824544:error:0306E06C:lib(3):func(110):reason(108):bn_gcd.c:233:
139858767824544:error:0306E06C:lib(3):func(110):reason(108):bn_gcd.c:233:
_
On 05/12/15 09:42, Judson Wilson wrote:
> I am noticing the following sequence of events:
>
> 1) SSL_renegotiate(...), followed by SSL_write(..., 0) fails when a web
> server rejects it by sending a TCP FIN
> 2) SSL_get_error returns SSL_ERROR_SSL
> 3) SSL_in_init(...) is true
> 4) SSL_shutdown
On 1/20/16, 5:10 , "Hubert Kario" wrote:
>On Tuesday 19 January 2016 22:16:23 Blumenthal, Uri - 0553 - MITLL wrote:
>> Looks good. I might add an *explicit* statement “pkeyutl does not
>> invoke the specified digest function”.
>>
>> Yes I realize it could be seen as repetitive. I’d much rather b
18.01.2016, 19:56, "Salz, Rich" :
> This is interesting, thanks.
>
> I am not sure how to read the charts; I'm probably being dumb.
>
> I wonder how master compares?
You can find comparison results for master and latest pre-releases on this
page: http://abi-laboratory.pro/tracker/timeline/openssl
On Tuesday 19 January 2016 22:16:23 Blumenthal, Uri - 0553 - MITLL
wrote:
> Looks good. I might add an *explicit* statement “pkeyutl does not
> invoke the specified digest function”.
>
> Yes I realize it could be seen as repetitive. I’d much rather be
> repetitive than risk misunderstanding. And
45 matches
Mail list logo
