Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

[John Denker via RT]

On 05/30/2016 08:58 PM, Viktor Dukhovni wrote:

> Name constraints in the X.509v3 PKI have not worked well, and are
> rarely used.  The attack requires a issuing CA to be willing to
> issue certificates beyond its constraints, that would be quite
> noticeable and rather unwise.  So I think this is not a major
> problem.  We should probably make a reasonable effort to address
> this, but the urgency is I think low.

The priority may be higher than that, because of something
that has not yet been mentioned in this discussion:

  The nameConstraints protect the issuing CA, not just
  the relying parties.

Here's the scenario:  I persuade 1000 of my closest friends
to accept my mumble.com CA as a trusted root.  I offer them
the assurance that:
  The root cert is name-constrained, and therefore affects
  only their interactions with *.mumble.com, so it's
  not very dangerous. [1]

The first problem is that if openssl does not implement
nameConstraints properly, my assertion [1] is false.

This leads to a second problem:  My cert-issuing machine
becomes a much juicier target.  If anybody pwns my machine,
then /every/ cert-based activity of /every one/ of my friends
is compromised, via the nameConstraints bypass bug.

The problem does not revolve around me intentionally doing
something unwise;  it involves a bad guy stealing from me
and then doing something nasty.

So it seems the priority / prevalence argument is at best
circular:  People would use the feature a lot more if they
could trust it to do the right thing.

As Fred Smith once said, you don't judge the importance or
the optimal size of the proposed bridge according to the
number of people seen driving across the river before the
bridge is built.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3502
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

[Viktor Dukhovni]

On Tue, May 31, 2016 at 02:54:13AM +, Brian Smith via RT wrote:

> > Applications can do that now by setting the right flag, as Viktor pointed
> > out.  I think it's too late to make the default change for 1.1
> 
> The important thing is: What happens when applications use the default
> settings? If the default settings are "don't consider the subject CN for
> name constraint processing, but do consider it for name validation" then
> that's obviously wrong and dangerous.

As of OpenSSL 1.0.2, we provide built-in name check support.  When
the built-in routines are enabled, we know whether the application
has asked us to check for DNS names (and which ones).

The built-in checks do accept CN-ID as a fallback in the absence
of DNS-IDs.  The name constraint code could make use of this to
apply name constraints to the CN-ID when we'll also be doing the
hostname checks on the CN-ID.

Now, not all (likely only a minority of) applications delegate name
checks to OpenSSL.  It is more difficult to protect applications
that do their own name checks.  If the sole name in the subject DN
is a valid DNS hostname, we could apply name constraints.  If it
is instead "Joe User", that won't look like a DNS name, and we
could ignore it.  That would be a bit of a hack, but it is not
clear that we can do any better when we have no idea what name
checks if any the application intends to perform.

Name constraints in the X.509v3 PKI have not worked well, and are
rarely used.  The attack requires a issuing CA to be willing to
issue certificates beyond its constraints, that would be quite
noticeable and rather unwise.  So I think this is not a major
problem.  We should probably make a reasonable effort to address
this, but the urgency is I think low.

-- 
Viktor.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

[Brian Smith]

Salz, Rich via RT  wrote:

> > 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.
>

As one example, mozilla::pkix treats the CN as a dNSName/iPAddress iif
there is no subjectAltName extension and iif the CN is a valid
dNSNa/iPAddress syntactically.


> Applications can do that now by setting the right flag, as Viktor pointed
> out.  I think it's too late to make the default change for 1.1
>

The important thing is: What happens when applications use the default
settings? If the default settings are "don't consider the subject CN for
name constraint processing, but do consider it for name validation" then
that's obviously wrong and dangerous.

Besides that, there needs to be a way to make name constraint processing
consistent with name validation. That means that if name validation is
configured (by default or with a switch) to look at subject CNs then the
name constraints need to be configurable to do the same. Name validation
and name constraint validation go hand-in-hand.


> > How about this for a heuristic:  If nameConstraints are in effect, then
> the
> > validator MUST NOT accept the CN as a DNS name.  This seems like the
> least
> > the validator could do, in light of the aforementioned deprecation.
>
> Probably.
>

If the validator has that much information then it should be simple for it
to keep the state in sync. But, often (usually?) certificate chain
validation and certificate name validation are done in separate steps by
applications, and it's difficult or impossible to keep things in sync in
that case.


> >  -- The problem is not solved until bad guys are
> >   /required/ to use SAN;
>
> Applications can make that happen now.


Again, what matters is less what applications *can* do and more what
applications *actually* do. I suspect that most applications are having the
wrong, dangerous, thing happen. In fact, that is almost definitely the
case, considering that many applications are doing their own name
validation (and thus almost definitely looking at the subject CN as that is
historically how it is done), as OpenSSL didn't provide a name validation
API until recently.

So, I agree with the others that OpenSSL is broken in this respect.

Cheers,
Brian
-- 
https://briansmith.org/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

[Brian Smith via RT]

Salz, Rich via RT  wrote:

> > 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.
>

As one example, mozilla::pkix treats the CN as a dNSName/iPAddress iif
there is no subjectAltName extension and iif the CN is a valid
dNSNa/iPAddress syntactically.


> Applications can do that now by setting the right flag, as Viktor pointed
> out.  I think it's too late to make the default change for 1.1
>

The important thing is: What happens when applications use the default
settings? If the default settings are "don't consider the subject CN for
name constraint processing, but do consider it for name validation" then
that's obviously wrong and dangerous.

Besides that, there needs to be a way to make name constraint processing
consistent with name validation. That means that if name validation is
configured (by default or with a switch) to look at subject CNs then the
name constraints need to be configurable to do the same. Name validation
and name constraint validation go hand-in-hand.


> > How about this for a heuristic:  If nameConstraints are in effect, then
> the
> > validator MUST NOT accept the CN as a DNS name.  This seems like the
> least
> > the validator could do, in light of the aforementioned deprecation.
>
> Probably.
>

If the validator has that much information then it should be simple for it
to keep the state in sync. But, often (usually?) certificate chain
validation and certificate name validation are done in separate steps by
applications, and it's difficult or impossible to keep things in sync in
that case.


> >  -- The problem is not solved until bad guys are
> >   /required/ to use SAN;
>
> Applications can make that happen now.


Again, what matters is less what applications *can* do and more what
applications *actually* do. I suspect that most applications are having the
wrong, dangerous, thing happen. In fact, that is almost definitely the
case, considering that many applications are doing their own name
validation (and thus almost definitely looking at the subject CN as that is
historically how it is done), as OpenSSL didn't provide a name validation
API until recently.

So, I agree with the others that OpenSSL is broken in this respect.

Cheers,
Brian
-- 
https://briansmith.org/

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3502
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

[Viktor Dukhovni via RT]

> 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.
> 
> Applications can do that now by setting the right flag, as Viktor pointed 
> out.  I think it's too late to make the default change for 1.1

Well, to be fair, I was proposing a new flag.  We don't yet have a flag to
suppress processing of CN in the absence of DNS-ID SANs.

-- 
Viktor.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3502
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

[Viktor Dukhovni]

> 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.
> 
> Applications can do that now by setting the right flag, as Viktor pointed 
> out.  I think it's too late to make the default change for 1.1

Well, to be fair, I was proposing a new flag.  We don't yet have a flag to
suppress processing of CN in the absence of DNS-ID SANs.

-- 
Viktor.

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

[Salz, Rich via RT]

> 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 de-implemented CN-as-hostname and actually
> mandated SAN, that would solve the nameConstraints bypass bug in grand
> style.

Applications can do that now by setting the right flag, as Viktor pointed out.  
I think it's too late to make the default change for 1.1

> How about this for a heuristic:  If nameConstraints are in effect, then the
> validator MUST NOT accept the CN as a DNS name.  This seems like the least
> the validator could do, in light of the aforementioned deprecation.

Probably.
 
>  -- The problem is not solved until bad guys are
>   /required/ to use SAN;

Applications can make that happen now.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3502
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] dead links in openssl docs

[Salz, Rich]

> https://www.openssl.org/docs/manmaster/apps/s_client.html
> has a link to
> https://www.openssl.org/docs/manmaster/apps/SSL_CONF_cmd.html
> 
> the latter doesn't exist.
> 
> Seems the correct URL is:
> https://www.openssl.org/docs/manmaster/ssl/SSL_CONF_cmd.html
> 
> I assume these are somehow autogenerated.

Yes.  https://github.com/openssl/web/blob/master/bin/mk-manpages

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] dead links in openssl docs

[Hanno Böck]

Hi,

https://www.openssl.org/docs/manmaster/apps/s_client.html
has a link to
https://www.openssl.org/docs/manmaster/apps/SSL_CONF_cmd.html

the latter doesn't exist.

Seems the correct URL is:
https://www.openssl.org/docs/manmaster/ssl/SSL_CONF_cmd.html

I assume these are somehow autogenerated.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgphcvkUwXBql.pgp
Description: OpenPGP digital signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

[John Denker via RT]

I'm glad to see some discussion of this issue.
Note that other implementations treated this as
a bug and fixed it a long time ago.

On 05/30/2016 11:56 AM, Rich Salz wrote:

> WebPKI has deprecated
> cn-as-hostname for more than a decade and mandated SAN names.

Well, maybe that is the Right Answer™

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.

> Leaving this open because we might be able to do some hueristics/hacks to
> determine when the CN "should be" a DNS name.

How about this for a heuristic:  If nameConstraints are
in effect, then the validator MUST NOT accept the CN as
a DNS name.  This seems like the least the validator
could do, in light of the aforementioned deprecation.

This seems unlikely to generate false alarms, since any
issuer who uses nameConstraints should be savvy enough 
to not rely on CN-as-hostname to the exclusion of SANs.

  Optionally a CN that satisfies the nameConstraints could
  be tolerated, insofar as it is deprecated but harmless.

>  But the workaround is to use SAN.

That workaround is not specific enough to solve the 
security problem.  Note the contrast:
 -- As it stands, good guys are /allowed/ to use SAN.
 -- The problem is not solved until bad guys are
  /required/ to use SAN;
 ... or more to the point, required to not use anything
  but SAN;
 ... or even more to the point, required to not use
  anything that bypasses the nameConstraints.

The crucial word there is "required".


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3502
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4549] powerpc test problem: missing symbols

[Andy Polyakov via RT]

> I'm seeing this on powerpc:
> ../test/recipes/01-test_ordinals.t . ok
> 
> #   Failed test 'check that there are no missing symbols in libcrypto.so'
> #   at ../test/recipes/01-test_symbol_presence.t line 112.
> # Looks like you failed 1 test of 4.
> ../test/recipes/01-test_symbol_presence.t .. 
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/4 subtests 
> 
> I a full log is at:
> https://buildd.debian.org/status/fetch.php?pkg=openssl=powerpc=1.1.0~pre5-1=1464595346
> 
> If I find time I'll try to look in the the real cause.

For what it's worth I can't reproduce problem on Fedora or RedHat.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4549
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4550] hppa assembler problem

[Kurt Roeckx via RT]

On Mon, May 30, 2016 at 08:37:56PM +, Andy Polyakov via RT wrote:
> > I'm getting assembler errors on hppa that look like:
> > crypto/aes/aes-parisc.s: Assembler messages:
> > crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa'
> > crypto/aes/aes-parisc.s:7: Error: Unknown opcode: `aes_encrypt'
> > crypto/aes/aes-parisc.s:11: Error: Missing function name for .PROC
> > crypto/aes/aes-parisc.s:12: Error: Missing function name for .PROC
> > 
> > I'm guessing I'm doing something wrong, but hppa never had
> > assembler enabled in Debian before.
> > 
> > The configuration I use is:
> > my $debian_cflags = `dpkg-buildflags --get CFLAGS` .  `dpkg-buildflags 
> > --get CPPFLAGS` . "-Wa,--noexecstack -Wall";
> > $debian_cflags =~ s/\n/ /g;
> > my $debian_ldflags = `dpkg-buildflags --get LDFLAGS`;
> > $debian_ldflags =~ s/\n/ /g;
> > 
> > 
> > %targets = (
> >"debian" => {
> >cflags => $debian_cflags,
> >lflags => add($debian_ldflags, "-pthread"),
> >},
> > [...]
> >"debian-hppa" => {
> >inherit_from => [ "linux-generic32", "debian", 
> > asm("parisc11_asm") ],
> >},
> > 
> > Is that assembler supposed to work?  Is it the right assembler that
> > I'm using?
> 
> PA-RISC assembly modules were tested *only* on HP-UX. While it works
> with GNU assembler, it's still one for HP-UX. Special thing about it is
> that run-time format is not ELF, and supposedly that's what those
> failing directives are about. I mean they are meant to make sense to
> specifically HP-UX assemblers. I suppose it means that Linux support
> would require extra work, adapting all modules to recognize additional
> "perlasm flavour". It's not unlike that it's not about simple
> decorations, ABI-specific adjustments might be required too... I don't
> think I've actually seen PA-RISC ELF calling convention...

Then I suggest you forget about it.  hppa isn't officially in
Debian anymore, I'll just drop the assembler support.


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4550
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4550] hppa assembler problem

[Kurt Roeckx]

On Mon, May 30, 2016 at 08:37:56PM +, Andy Polyakov via RT wrote:
> > I'm getting assembler errors on hppa that look like:
> > crypto/aes/aes-parisc.s: Assembler messages:
> > crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa'
> > crypto/aes/aes-parisc.s:7: Error: Unknown opcode: `aes_encrypt'
> > crypto/aes/aes-parisc.s:11: Error: Missing function name for .PROC
> > crypto/aes/aes-parisc.s:12: Error: Missing function name for .PROC
> > 
> > I'm guessing I'm doing something wrong, but hppa never had
> > assembler enabled in Debian before.
> > 
> > The configuration I use is:
> > my $debian_cflags = `dpkg-buildflags --get CFLAGS` .  `dpkg-buildflags 
> > --get CPPFLAGS` . "-Wa,--noexecstack -Wall";
> > $debian_cflags =~ s/\n/ /g;
> > my $debian_ldflags = `dpkg-buildflags --get LDFLAGS`;
> > $debian_ldflags =~ s/\n/ /g;
> > 
> > 
> > %targets = (
> >"debian" => {
> >cflags => $debian_cflags,
> >lflags => add($debian_ldflags, "-pthread"),
> >},
> > [...]
> >"debian-hppa" => {
> >inherit_from => [ "linux-generic32", "debian", 
> > asm("parisc11_asm") ],
> >},
> > 
> > Is that assembler supposed to work?  Is it the right assembler that
> > I'm using?
> 
> PA-RISC assembly modules were tested *only* on HP-UX. While it works
> with GNU assembler, it's still one for HP-UX. Special thing about it is
> that run-time format is not ELF, and supposedly that's what those
> failing directives are about. I mean they are meant to make sense to
> specifically HP-UX assemblers. I suppose it means that Linux support
> would require extra work, adapting all modules to recognize additional
> "perlasm flavour". It's not unlike that it's not about simple
> decorations, ABI-specific adjustments might be required too... I don't
> think I've actually seen PA-RISC ELF calling convention...

Then I suggest you forget about it.  hppa isn't officially in
Debian anymore, I'll just drop the assembler support.


Kurt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4550] hppa assembler problem

[Andy Polyakov via RT]

> I'm getting assembler errors on hppa that look like:
> crypto/aes/aes-parisc.s: Assembler messages:
> crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa'
> crypto/aes/aes-parisc.s:7: Error: Unknown opcode: `aes_encrypt'
> crypto/aes/aes-parisc.s:11: Error: Missing function name for .PROC
> crypto/aes/aes-parisc.s:12: Error: Missing function name for .PROC
> 
> I'm guessing I'm doing something wrong, but hppa never had
> assembler enabled in Debian before.
> 
> The configuration I use is:
> my $debian_cflags = `dpkg-buildflags --get CFLAGS` .  `dpkg-buildflags --get 
> CPPFLAGS` . "-Wa,--noexecstack -Wall";
> $debian_cflags =~ s/\n/ /g;
> my $debian_ldflags = `dpkg-buildflags --get LDFLAGS`;
> $debian_ldflags =~ s/\n/ /g;
> 
> 
> %targets = (
>"debian" => {
>cflags => $debian_cflags,
>lflags => add($debian_ldflags, "-pthread"),
>},
> [...]
>"debian-hppa" => {
>inherit_from => [ "linux-generic32", "debian", 
> asm("parisc11_asm") ],
>},
> 
> Is that assembler supposed to work?  Is it the right assembler that
> I'm using?

PA-RISC assembly modules were tested *only* on HP-UX. While it works
with GNU assembler, it's still one for HP-UX. Special thing about it is
that run-time format is not ELF, and supposedly that's what those
failing directives are about. I mean they are meant to make sense to
specifically HP-UX assemblers. I suppose it means that Linux support
would require extra work, adapting all modules to recognize additional
"perlasm flavour". It's not unlike that it's not about simple
decorations, ABI-specific adjustments might be required too... I don't
think I've actually seen PA-RISC ELF calling convention...



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4550
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4548] s390x build problem

[Andy Polyakov via RT]

> I'm getting:
> crypto/chacha/chacha-s390x.S: Assembler messages:
> crypto/chacha/chacha-s390x.S:7: Error: Unrecognized opcode: `clgije'
> 
> 
> A full build log is available on:
> https://buildd.debian.org/status/fetch.php?pkg=openssl=s390x=1.1.0~pre5-1=1464594754

It's overly easy to get carried away if you have access to single
system. Double-check attached.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4548
Please log in as guest with password guest if prompted

commit fbaecaa94021294f4dd3f399338d076af284f787
Author: Andy Polyakov 
Date:   Mon May 30 22:16:31 2016 +0200

chacha/asm/chacha-s390x.pl: improve portability.

cl[g]ije is an extension instruction, there is no real reason to
limit ourselves to specific processors.

diff --git a/crypto/chacha/asm/chacha-s390x.pl 
b/crypto/chacha/asm/chacha-s390x.pl
index c7a2692..867594f 100755
--- a/crypto/chacha/asm/chacha-s390x.pl
+++ b/crypto/chacha/asm/chacha-s390x.pl
@@ -147,7 +147,8 @@ $code.=<<___;
 .type  ChaCha20_ctr32,\@function
 .align 32
 ChaCha20_ctr32:
-   cl${g}ije   $len,0,.Lno_data# $len==0?
+   cl${g}fi$len,0
+   je  .Lno_data   # $len==0?
a${g}hi $len,-64
l${g}hi %r1,-$frame
stm${g} %r6,%r15,`6*$SIZE_T`($sp)
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4550] hppa assembler problem

[Kurt Roeckx via RT]

Hi,

I'm getting assembler errors on hppa that look like:
crypto/aes/aes-parisc.s: Assembler messages:
crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa'
crypto/aes/aes-parisc.s:7: Error: Unknown opcode: `aes_encrypt'
crypto/aes/aes-parisc.s:11: Error: Missing function name for .PROC
crypto/aes/aes-parisc.s:12: Error: Missing function name for .PROC

I'm guessing I'm doing something wrong, but hppa never had
assembler enabled in Debian before.

The configuration I use is:
my $debian_cflags = `dpkg-buildflags --get CFLAGS` .  `dpkg-buildflags --get 
CPPFLAGS` . "-Wa,--noexecstack -Wall";
$debian_cflags =~ s/\n/ /g;
my $debian_ldflags = `dpkg-buildflags --get LDFLAGS`;
$debian_ldflags =~ s/\n/ /g;


%targets = (
   "debian" => {
   cflags => $debian_cflags,
   lflags => add($debian_ldflags, "-pthread"),
   },
[...]
   "debian-hppa" => {
   inherit_from => [ "linux-generic32", "debian", 
asm("parisc11_asm") ],
   },

Is that assembler supposed to work?  Is it the right assembler that
I'm using?

A full log can bee seen at:
buildd.debian.org/status/fetch.php?pkg=openssl=hppa=1.1.0~pre5-1=1464595947


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4550
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4549] powerpc test problem: missing symbols

[Kurt Roeckx via RT]

Hi,

I'm seeing this on powerpc:
../test/recipes/01-test_ordinals.t . ok

#   Failed test 'check that there are no missing symbols in libcrypto.so'
#   at ../test/recipes/01-test_symbol_presence.t line 112.
# Looks like you failed 1 test of 4.
../test/recipes/01-test_symbol_presence.t .. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests 

I a full log is at:
https://buildd.debian.org/status/fetch.php?pkg=openssl=powerpc=1.1.0~pre5-1=1464595346

If I find time I'll try to look in the the real cause.


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4549
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4548] s390x build problem

[Kurt Roeckx via RT]

Hi,

I'm getting:
crypto/chacha/chacha-s390x.S: Assembler messages:
crypto/chacha/chacha-s390x.S:7: Error: Unrecognized opcode: `clgije'


A full build log is available on:
https://buildd.debian.org/status/fetch.php?pkg=openssl=s390x=1.1.0~pre5-1=1464594754


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4548
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

[Viktor Dukhovni]

On Mon, May 30, 2016 at 06:56:17PM +, Rich Salz via RT wrote:

> If there is no altname and there is a CN, we cannot assume that the CN is a
> hostname. Yes, for WebPKI this is true, but WebPKI has deprecated
> cn-as-hostname for more than a decade and mandated SAN names.

OpenSSL master supports internal host name checks via SSL_add1_host(),
X509_VERIFY_PARAM_set1_host(), or (less recommended) X509_check_host().
Various flags modify the behaviour of the built-in name checks:

SSL_set_hostflags(3)
X509_VERIFY_PARAM_set_hostflags(3)

In particular, we support the X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT
flag to make it possible to always consider the subject CN even
when DNS SANs are present.  That flag is off by default and should
not be used:

https://tools.ietf.org/html/rfc6125#section-6.3

  Security Warning: A client MUST NOT seek a match for a reference
  identifier of CN-ID if the presented identifiers include a DNS-ID,
  SRV-ID, URI-ID, or any application-specific identifier types
  supported by the client.

Should there perhaps also be a new

X509_CHECK_FLAG_NEVER_CHECK_SUBJECT

flag that would ask us to never match the subject CN against DNS
reference identifiers?  And what should the default behaviour be?
(Should the new flag be on by default, requiring an explicit call
to SSL_set_hostflags(3) or X509_VERIFY_PARAM_set_hostflags(3) to
override the flag?)

-- 
Viktor.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4189] PR #512: Clean up Windows RNG

[Matt Caswell via RT]

On Mon Dec 21 11:07:24 2015, dra...@dancingdragon.be wrote:
> https://github.com/openssl/openssl/pull/512
>
> This PR removes all of the dangerous Windows entropy gathering routines
> in favor of standard CryptGenRandom calls, as was discussed in the
> "Improving OpenSSL default RNG" thread on openssl-dev. This fixes
> common, repeatable crashes that happen when running openssl under the VS
> debugger.

For the record this became this pull request and has now been merged:

https://github.com/openssl/openssl/pull/1079

Closing this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4189
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3502] nameConstraints bypass bug

[Rich Salz via RT]

The existing code is working as designed and is basically correct.

If there is no altname and there is a CN, we cannot assume that the CN is a
hostname. Yes, for WebPKI this is true, but WebPKI has deprecated
cn-as-hostname for more than a decade and mandated SAN names.

For example, in validating a cert chain for s/mime, suppose we have a
certificate chain which includes name constraints on DNS (say restricting it to
.foo.com) and the EE certificate has no subject alternative name. Do we reject
the chain because "Fred Bloggs" violates name constraints? Clearly, no.

Leaving this open because we might be able to do some hueristics/hacks to
determine when the CN "should be" a DNS name. But the workaround is to use SAN.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3502
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4547] Changing function CRYPTO_num_locks() to "#define CRYPTO_num_locks() (0)" breaks compiles

[Rich Salz via RT]

BOOST has work (perhaps a lot) to do to support 1.1 In particular, their ASIO
stuff needs to be reworked to use the new ASYNC stuff, and papering over
compile-time differences are most likely going to lead to semantic mismatches,
dogs and cats living together, and crashes and coredumps oh my.

Closing this ticket.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4547
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev