[Pkg-openssl-devel] Bug#829272: Fwd: [openssl.org #4602] Missing accessors

[Mischa Salle]

Hi Richard, Mattias, others,

I agree with you that it would be nice if OpenSSL could figure out
itself whether a cert needs to be treated as a proxy, but currently that
doesn't work reliably as far as I know.
The flag is certainly needed in the case of non-RFC3820 proxies, also
known as legacy proxies. Unfortunately these are still very widely used
(majority of the proxies actually) and hence our code must be able to
handle them correctly.

Best wishes,
Mischa Sallé


On Mon, Jul 11, 2016 at 12:16:48PM +0000, rt at openssl.org wrote:
> 
> This is forward of transaction #70156 of a ticket #4602
> 
> -------------------------------------------------------------------------
> http://rt.openssl.org/Ticket/Display.html?id=4602
> 
> Please log in as guest with password guest if prompted

> X-Mailer: MIME-tools 5.505 (Entity 5.505)
> 
> 
>    On Mon Jul 11 11:34:35 2016, mattias.ellert at physics.uu.se wrote:
>    > fre 2016-07-08 klockan 00:42 +0200 skrev Kurt Roeckx:
>    > > Mattias,
>    > >
>    > > Can you explain why this is needed, what the code is trying to do?
>    > >
>    > >
>    > > Kurt
>    > >
>    >
>    > Hi!
>    >
>    > The modification of the extension flags happens in at least four
>    > different packages. The modification they do is to add the
>    > EXFLAG_PROXY
>    > bit to the flags.
>    Ok, I just had a look:
>    >
>    https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus
>    _gsi_callback.c/#L692
>    This looks like an old workaround, and I wonder if it's really needed
>    any more.  If it's still needed, I'd say this may uncover a bug within
>    OpenSSL, but in that case, I'd rather fix that in 1.1
>    >
>    https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L
>    1665
>    >
>    https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L
>    1740
>    I see what this code does, it makes a name constraint check that should
>    have been present in OpenSSL but wasn't...  until 1.1.  However,
>    there's other stuff in that function that looks odd..
>    >
>    https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L16
>    55
>    >
>    https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L17
>    19
>    This is the same code as the voms you pointed at above.
>    >
>    https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/crede
>    ntial/CertUtil.cpp/#L184
>    This is the same code as the globus-gsi-callback pointer above.
>    > I guess having a more restrictive accessor that only sets the
>    > EXFLAG_PROXY bit could work. I suggested the more general solution of
>    > having set/clear accessors for arbitrary flags since it was - well
>    > more
>    > general.
>    Mm, I'm really unsure about this one.  ex_flags is part of a cache of
>    information that OpenSSL fiddles with whenever it checks the extensions
>    for a certificate.  Calling anything that ends up
>    calling X509_check_issued(), X509_check_ca() or X509_check_purpose()
>    will cause values to be checked and cached for the certificates
>    involved in the call of those functions.  In the proxy certificate
>    case, EXFLAG_PROXY will be set for a certificate any time
>    the proxyCertInfo is found among its extensions.
>    To be blunt, I would much rather see a bug report that shows when that
>    cache isn't being built properly, and possibly a fix for it.
>    Cheers,
>    Richard
>    --
>    Richard Levitte
>    levitte at openssl.org


-- 
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email msalle at nikhef.nl
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-openssl-devel/attachments/20160711/a6e4e66f/attachment.sig>