Re: [cp-patches] GNU Crypto and Jessie merge

[Raif S. Naffah]

hello Mark and Casey,

(i'm cc-ing Tom on this)

On Friday 06 January 2006 06:45, Casey Marshall wrote:
> On Jan 5, 2006, at 3:58 AM, Mark Wielaard wrote:
> > On Sun, 2005-12-25 at 17:06 -0800, Casey Marshall wrote:
> >> I've moved GNU Crypto and Jessie into my Classpath tree,
> >> approximately as I proposed to do earlier...
> >> ...
> >> Does this otherwise look OK to commit?
> >
> > Administrativia: The standard boilerplate at the top of each file
> > should be updated....
>
> Yeah, copyright headers need to be changed. I didn't do this for this
> patch because it's tedious to do so. If this can be automated to a
> degree, that will help a lot.
>
> Of course, a lot of GNU Crypto's source is formatted in a completely
> non-standard way: the file opens with the 'package' line, then the
> copyright boilerplate (with // comments), then the class. And, the
> source is formatted with non-GNU style indentation, and an indent
> length of 3. I remember seeing code reformatters mentioned here
> before; will they work here? Is it worth reformatting all this code?

Tom Tromey, some time ago, worked on Jalopy, to customize it to suit GNU 
formatting standard purposes.  he may be able to shed some light on the 
tool's fitness for this purpose.  if it works that can solve this issue 
--and a similar one in the Mauve part for the corresponding testlets.


> >> I know some have expressed
> >> concern over including crypto in Classpath, and wanted to know if
> >> the configure switch will suffice for them.
> >
> > I am not sure the --disable-crypto part is enough to disable all
> > crypto[-hooks] so I would only include this if Anthony confirms
> > this is
> > really what is needed to make the resulting binary "exportable" for
> > him.
> > If not then I think we should not include it because people might
> > rely on that switch to purge all crypto things. (We already have
> > crypto in GNU Classpath since the 0.11 release, this only adds more
> > and stronger algorithms.)
>
> We could extend the --disable-crypto option to disable the
> javax.crypto and javax.net.ssl hooks, as well, if that will meet the
> needs for exportable classpath. It's easy to do that by adding
> patterns to the omit file.
>
> And, the --disable-crypto option should be refined, because now it
> eliminates everything from GNU Crypto, even the stuff that is
> exportable. We can do this after the merge, though: it will be easier
> (I think) to push the classes into the tree, as close to as they
> exist now, and then refine things.

indeed.  my proposed plan was (a) to get in the tree as much GNU Crypto 
code as possible, and (b) to address Anthony's concern about the 
exportability of the code --i look forward to see his reply re. how he 
is dealing with the existing crypto-related stuff in the current 
Classpath's HEAD.

this patch does (a) and allows, in time, to address (b).


some more refinements, which can be done subsequent to the merge --and 
which i can work on if there are no objection (i'd hate to do the work, 
submit a patch and then get a negative response)-- follow:

* combine the GNU and the GNU_SECURITY providers into one, and leave the 
other providers.
* ensure that internally, to Classpath, all crypto-related classes use 
the gnu.javax.crypto classes.


> ...
> This will probably happen after 0.20.

if you haven't done so already, i can work on the Mauve part.  


cheers;
rsn

pgpDnQiyX7BkF.pgp
Description: PGP signature