> On Aug 9, 2016, at 2:52 PM, Salz, Rich via RT wrote:
>
> As Viktor pointed out, this doesn't work in 1.0.1
The story is a bit more complicated. What's really going on is that
root (self-signed) CAs in the trust store are backwards-compatible
implicit trust-anchors for all purposes. Intermed
> On Jul 19, 2016, at 5:26 PM, Matt Caswell via RT wrote:
>
>> Most of all, we use CRYPTO_THREAD_run_once() internally to initiate the first
>> locks, so pretty much in an initial state of the library (not entirely true,
>> since we do these inits opportunistically, but it's probable that they h
> On May 31, 2016, at 1:15 PM, Rich Salz via RT wrote:
>
> I do not understand what should be done for this ticket. Call me stupid :)
I took care of the requisite changes already. Feel free to close the ticket.
--
Viktor.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id
> On May 30, 2016, at 10:06 PM, Salz, Rich via RT wrote:
>
>> I'm not sure what "deprecated" and "mandated" mean in the openssl
>> context. If openssl actually de-implemented CN-as-hostname and actually
>> mandated SAN, that would solve the nameConstraints bypass bug in grand
>> style.
>
> App
Beyond the suggested changes to SCT_LIST_validate() et. al.
and documentation, IIRC at some point or other I noted that
the chain verification status observed in resumed sessions
may not be correct if handshakes without valid SCTs are
allowed to complete and perhaps get reused.
Even without resum
> On Apr 2, 2016, at 10:05 AM, Daniel Gruszczyk via RT wrote:
>
> Hi,I was playing with a ciphers app to create example list of suites. Looking
> at the website (https://openssl.org/docs/manmaster/apps/ciphers.html) if I
> run one of the examples there:
> openssl ciphers -v '3DES:+RSA'I suppos
> On Mar 28, 2016, at 4:38 AM, noloa...@gmail.com via RT
> wrote:
>
> On Windows, the fix below also depends upon the patch from Issue 4488
> ("The POSIX name for this item is deprecated. Instead, use the ISO C++
> conformant name...").
>
> This patch below also fixes some problems with the ol
> On Mar 24, 2016, at 12:38 AM, noloa...@gmail.com via RT
> wrote:
>
> I can understand lack of resources.
>
> Lack of interest can be dealt with in the engineering process. Place a
> quality gate, and make the code pass through it. I'd wager folks will
> take interest if/when it blocks a rele
> On Mar 23, 2016, at 7:47 PM, noloa...@gmail.com via RT
> wrote:
>
> I'm not sure if this is a supported configuration, but I'm guessing
> there are going to be users in the filed who find themselves in it,
> like http://stackoverflow.com/q/36188982.
>
> Working from the tip of Master...
>
>
> On Mar 21, 2016, at 11:51 AM, Tiantian Liu via RT wrote:
>
>
> srp_ctx = {SRP_cb_arg = 0x0, TLS_ext_srp_username_callback = 0,
> SRP_verify_param_callback = 0, SRP_give_srp_client_pwd_callback = 0,
>login = 0x44454c4c , N = 0x9a285f8, g =
> 0x61, s = 0x9a29820, B = 0xdbd150, A = 0x0, a
When a certificate is re-signed via "x509 -signkey" while keeping the
existing extensions (i.e. without "-clrext"), the (unwritten) expectation
is that that all that's being changed is the validity dates, and the
previous certificate content remains unchanged. Yes, the issuer is updated
to match
> On Feb 4, 2016, at 3:37 PM, Rich Salz via RT wrote:
>
> Rather than replacing all the getenv() calls, a simple wrapper like
> OPENSSL_safe_getenv() that includes the issetguid test seems a lot cleaner.
> And
> the config changes needed to be ported up to master.
Where available, this should
> On Feb 3, 2016, at 4:18 PM, Daniel Kahn Gillmor via RT
> wrote:
>
> if the cert at the top of the chain is self-signed, it's entirely
> reasonable to say that the expiration date is meaningful. For example,
> I could distribute a certificate for a root authority which i intend to
> only be u
> On Feb 1, 2016, at 2:32 PM, Rich Salz via RT wrote:
>
> This is reported against 0.9.x and/or 1.0.0; please open a new ticket if still
> a problem with current releases.
This was recently fixed in 1.0.2 and 1.1.0-dev. Since 1.0.1 now gets security
fixes only, it will likely remain unfixed in
> On Feb 1, 2016, at 2:21 PM, Rich Salz via RT wrote:
>
> This is reported against 0.9.x; please open a new ticket if still a problem
> with current releases.
Fixes for this problem are slated to appear in the next 1.0.2 patch level
and next 1.1.0 alpha release after initial internal review.
I
> On Jan 29, 2016, at 4:59 AM, Kiyoshi KANAZAWA via RT wrote:
>
> cc -I.. -I../.. -I../modes -I../include -I../../include -DOPENSSL_THREADS
> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xarch=generic64 -xstrconst -Xa
> -DL_ENDIAN -DFILIO_H -xO5 -xdepend -xbuiltin -DOPENSSL_IA32_SSE2
> -DOPENSSL
> On Jan 16, 2016, at 3:56 PM, Claus Assmann via RT wrote:
>
> -int depth = SSL_get0_dane_authority(s, NULL, &mspki);
> +int depth = SSL_get0_dane_authority(ssl, NULL, &mspki);
> -(void) SSL_get0_dane_tlsa(s, &usage, &selector, &mtype, NULL, NULL);
> +(void) SSL_get0_dane
> On Jan 15, 2016, at 10:32 AM, baldu...@units.it via RT
> wrote:
>
> This seems to be the reason why trying to build openssh-7.1p2 (with
> -DOPENSSL_API_COMPAT=0x1000L) fails with:
>
>In file included from ssh_api.h:26:0,
> from ssh_api.c:21:
>cipher.h:69:17: e
> On Jan 15, 2016, at 10:32 AM, Zi Lin via RT wrote:
>
>
Yes, this will get fixed. Thanks.
--
Viktor.
smime.p7s
Description: S/MIME cryptographic signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/
> On Jan 13, 2016, at 11:18 PM, Srinivas Koripella via RT
> wrote:
>
> Thanks ViKtor. I tested your patch and it is holding up well on our
> environment.
This is now in the git versions of all supported branches:
1.0.1, 1.0.1 and master == 1.1.0-dev
So you can test those, or wait fo
> On Jan 13, 2016, at 6:36 PM, Zak Blacher via RT wrote:
>
> Darn, and I was hoping to be able to patch it myself :)
The 1.1.0 fix is now on Github, and will be in 1.1.0-alpha2.
Similar changes can be made to earlier releases, the bulk
of the work is making the test-suite run again, given that
On Wed, Jan 13, 2016 at 06:58:14PM +, Zak Blacher via RT wrote:
> I've found an inconsistency in the return status of 'openssl verify'. I've
> attached a custom dummy ca, and an example certificate. This certificate is
> valid for some date range in the future.
>
> On my redhat machine (opens
> On Jan 12, 2016, at 6:35 AM, Ole Tange via RT wrote:
>
> On Tue, Jan 12, 2016 at 7:02 AM, Rich Salz via RT wrote:
>> Fixed in bd4850df648bee9d8e0595b7e1147266e6f55a3e
>
> Great to see.
>
> May I suggest the bug also becomes a wish for support for > 2GB
> numbers, as that is what the user or
> On Jan 11, 2016, at 7:01 PM, Salz, Rich via RT wrote:
>
>> 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 dea
24 matches
Mail list logo
