On 10/25/06, Garrett Rooney <[EMAIL PROTECTED]> wrote:
On 10/24/06, Cliff Schmidt <[EMAIL PROTECTED]> wrote:
> On 10/17/06, Garrett Rooney <[EMAIL PROTECTED]> wrote:
> > I'm not clear if my link to the OpenSSL sources
> > directory is correct, since it's not linking to a specific tarball
> > like the bouncy castle links do for James, and I'm not sure if I
>
> Whether you link directly to the right source or specify the version
> number somewhere and link to a higher level page, there should be some
> way that a BIS admin/enforcement person can look at the information
> and find the source for all crypto that we are distributing. So, in
> this case, I'm not sure why you wouldn't want to link directly to the
> source.
Well, primarily because I don't want to have to update the link every
time someone ships a build that bundles a new patch release of
OpenSSL. If there's no way around that, fine, but it would be more
convenient to be able to just point to their source directory.
If we ship a release that bundles a new build of OpenSSL, and
somewhere included in that release is a means to identify which build
of OpenSSL is included, I would think that could allow you to link to
the higher level OpenSSL source directory.
All we have to do is to make it reasonable for a BIS person to look at
the product we shipped (with any included notes about what versions of
some external crypto library are included) and match it with this
RDF-generated list of source code pointers to be able to identify the
source code that was included or used to build the crypto
functionality of the product.
I don't think we have to take arduous steps to make it easy for them,
but all the info they would need has to be reasonably easy to find in
either the product itself or in the RDF file.
Cliff
