Idea for a new project: gentoo-libs

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Idea for a new project: gentoo-libs

Marty E. Plummer
So, as you may be aware I've been doing some work on moving bzip2 to an
autotools based build. Recently I've ran into app-crypt/mhash, which is
in a semi-abandoned state (talking with the maintainer on twitter atm),
and I was thinking it may be a good idea to set up a project for keeping
these semi-abandoned and really-abandoned libraries and projects up to
date and such.

Basically, an upstream for packages who's upstream is either
uncontactable or is otherwise not accepting bug fixes and patches. So
far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
there are others in this state.

Reply | Threaded
Open this post in threaded view
|

Re: Idea for a new project: gentoo-libs

Marty E. Plummer
On Fri, Jun 22, 2018 at 09:50:50PM -0500, Marty E. Plummer wrote:

> So, as you may be aware I've been doing some work on moving bzip2 to an
> autotools based build. Recently I've ran into app-crypt/mhash, which is
> in a semi-abandoned state (talking with the maintainer on twitter atm),
> and I was thinking it may be a good idea to set up a project for keeping
> these semi-abandoned and really-abandoned libraries and projects up to
> date and such.
>
> Basically, an upstream for packages who's upstream is either
> uncontactable or is otherwise not accepting bug fixes and patches. So
> far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
> there are others in this state.
>
Or... call it proxy-upstream, to be in line with the current proxy-maint
setup?

Reply | Threaded
Open this post in threaded view
|

Re: Idea for a new project: gentoo-libs

Michał Górny-5
In reply to this post by Marty E. Plummer
W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E.
Plummer napisał:

> So, as you may be aware I've been doing some work on moving bzip2 to an
> autotools based build. Recently I've ran into app-crypt/mhash, which is
> in a semi-abandoned state (talking with the maintainer on twitter atm),
> and I was thinking it may be a good idea to set up a project for keeping
> these semi-abandoned and really-abandoned libraries and projects up to
> date and such.
>
> Basically, an upstream for packages who's upstream is either
> uncontactable or is otherwise not accepting bug fixes and patches. So
> far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
> there are others in this state.
>
So in order to fix problem of semi-abandoned packages, you're creating
an indirect herd-like entity that will soon be semi-abandoned itself
because people will be dumping random packages into it and afterwards
nobody will claim responsibility for them.

--
Best regards,
Michał Górny

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Idea for a new project: gentoo-libs

Marty E. Plummer
On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote:

> W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E.
> Plummer napisał:
> > So, as you may be aware I've been doing some work on moving bzip2 to an
> > autotools based build. Recently I've ran into app-crypt/mhash, which is
> > in a semi-abandoned state (talking with the maintainer on twitter atm),
> > and I was thinking it may be a good idea to set up a project for keeping
> > these semi-abandoned and really-abandoned libraries and projects up to
> > date and such.
> >
> > Basically, an upstream for packages who's upstream is either
> > uncontactable or is otherwise not accepting bug fixes and patches. So
> > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
> > there are others in this state.
> >
>
> So in order to fix problem of semi-abandoned packages, you're creating
> an indirect herd-like entity that will soon be semi-abandoned itself
> because people will be dumping random packages into it and afterwards
> nobody will claim responsibility for them.
>
> --
> Best regards,
> Michał Górny

No, I mean for packages which are important enough in gentoo to warrant
such treatment. For instance, every email I've tried for bzip2's
upstream bounced or recieved no reply. That, I assume, is important
enough to actually maintain and improve. Any other library which may be
as important which are as inactive would be added.

Reply | Threaded
Open this post in threaded view
|

Re: Idea for a new project: gentoo-libs

Michał Górny-5
W dniu sob, 23.06.2018 o godzinie 02∶30 -0500, użytkownik Marty E.
Plummer napisał:

> On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote:
> > W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E.
> > Plummer napisał:
> > > So, as you may be aware I've been doing some work on moving bzip2 to an
> > > autotools based build. Recently I've ran into app-crypt/mhash, which is
> > > in a semi-abandoned state (talking with the maintainer on twitter atm),
> > > and I was thinking it may be a good idea to set up a project for keeping
> > > these semi-abandoned and really-abandoned libraries and projects up to
> > > date and such.
> > >
> > > Basically, an upstream for packages who's upstream is either
> > > uncontactable or is otherwise not accepting bug fixes and patches. So
> > > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
> > > there are others in this state.
> > >
> >
> > So in order to fix problem of semi-abandoned packages, you're creating
> > an indirect herd-like entity that will soon be semi-abandoned itself
> > because people will be dumping random packages into it and afterwards
> > nobody will claim responsibility for them.
> >
> > --
> > Best regards,
> > Michał Górny
>
> No, I mean for packages which are important enough in gentoo to warrant
> such treatment. For instance, every email I've tried for bzip2's
> upstream bounced or recieved no reply. That, I assume, is important
> enough to actually maintain and improve. Any other library which may be
> as important which are as inactive would be added.
Sounds like you're going to take over half of base-system ;-).

I really prefer having single dedicated individuals for that kind of
stuff.  Projects just blur the responsibility.

--
Best regards,
Michał Górny

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Idea for a new project: gentoo-libs

Mikle Kolyada-2
In reply to this post by Marty E. Plummer


On 23.06.2018 05:50, Marty E. Plummer wrote:
> So, as you may be aware I've been doing some work on moving bzip2 to an
> autotools based build. Recently I've ran into app-crypt/mhash, which is
> in a semi-abandoned state (talking with the maintainer on twitter atm),
> and I was thinking it may be a good idea to set up a project for keeping
> these semi-abandoned and really-abandoned libraries and projects up to
> date and such.

But how would it serve gentoo itself? Lots of packages in the distro
have dead upstream but still work.
Why would you want to make gentoo an upstream area rather than moving a
dead project itself, say,
to github and do the job there?
>
> Basically, an upstream for packages who's upstream is either
> uncontactable or is otherwise not accepting bug fixes and patches. So
> far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
> there are others in this state.
>



signature.asc (321 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Idea for a new project: gentoo-libs

Paweł Hajdan, Jr.
On 23/06/2018 09:43, Mikle Kolyada wrote:
> But how would it serve gentoo itself? Lots of packages in the distro
> have dead upstream but still work.
> Why would you want to make gentoo an upstream area rather than moving a
> dead project itself, say,
> to github and do the job there?

+1

I like the idea of taking responsibility for the abandoned packages that
are still useful.

It's probably not Gentoo-specific, so a distro-neutral way of handling
that seems most appropriate.

It may even be worth it to coordinate with other distros (and maybe
downstreams) so that the new version becomes a standard.

Finally, having more than one person on this (to help continuity), and a
common platform like GitHub also seem very helpful.

Paweł


signature.asc (844 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Idea for a new project: gentoo-libs

Marty E. Plummer
On Sat, Jun 23, 2018 at 10:15:06AM +0200, Paweł Hajdan, Jr. wrote:

> On 23/06/2018 09:43, Mikle Kolyada wrote:
> > But how would it serve gentoo itself? Lots of packages in the distro
> > have dead upstream but still work.
> > Why would you want to make gentoo an upstream area rather than moving a
> > dead project itself, say,
> > to github and do the job there?
>
> +1
>
> I like the idea of taking responsibility for the abandoned packages that
> are still useful.
>
> It's probably not Gentoo-specific, so a distro-neutral way of handling
> that seems most appropriate.
>
> It may even be worth it to coordinate with other distros (and maybe
> downstreams) so that the new version becomes a standard.
>
> Finally, having more than one person on this (to help continuity), and a
> common platform like GitHub also seem very helpful.
>
> Paweł
>
Agreed in general; the problem is getting it started at all; difficult
to get other distros to join if there is nothing to join.

Reply | Threaded
Open this post in threaded view
|

Re: Idea for a new project: gentoo-libs

Alec Warner-2
In reply to this post by Marty E. Plummer


On Sat, Jun 23, 2018 at 3:30 AM, Marty E. Plummer <[hidden email]> wrote:
On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote:
> W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E.
> Plummer napisał:
> > So, as you may be aware I've been doing some work on moving bzip2 to an
> > autotools based build. Recently I've ran into app-crypt/mhash, which is
> > in a semi-abandoned state (talking with the maintainer on twitter atm),
> > and I was thinking it may be a good idea to set up a project for keeping
> > these semi-abandoned and really-abandoned libraries and projects up to
> > date and such.
> >
> > Basically, an upstream for packages who's upstream is either
> > uncontactable or is otherwise not accepting bug fixes and patches. So
> > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
> > there are others in this state.
> >
>
> So in order to fix problem of semi-abandoned packages, you're creating
> an indirect herd-like entity that will soon be semi-abandoned itself
> because people will be dumping random packages into it and afterwards
> nobody will claim responsibility for them.
>
> --
> Best regards,
> Michał Górny

No, I mean for packages which are important enough in gentoo to warrant
such treatment. For instance, every email I've tried for bzip2's
upstream bounced or recieved no reply. That, I assume, is important
enough to actually maintain and improve. Any other library which may be
as important which are as inactive would be added.


I suspect this might be better done in the Linux foundation itself as they have staffing for core components that everyone is using.

-A



Reply | Threaded
Open this post in threaded view
|

Re: Idea for a new project: gentoo-libs

Roy Bamford-2
In reply to this post by Marty E. Plummer
On 2018.06.23 09:55, Marty E. Plummer wrote:

> On Sat, Jun 23, 2018 at 10:15:06AM +0200, Paweł Hajdan, Jr. wrote:
> > On 23/06/2018 09:43, Mikle Kolyada wrote:
> > > But how would it serve gentoo itself? Lots of packages in the
> distro
> > > have dead upstream but still work.
> > > Why would you want to make gentoo an upstream area rather than
> moving a
> > > dead project itself, say,
> > > to github and do the job there?
> >
> > +1
> >
> > I like the idea of taking responsibility for the abandoned packages
> that
> > are still useful.
> >
> > It's probably not Gentoo-specific, so a distro-neutral way of
> handling
> > that seems most appropriate.
> >
> > It may even be worth it to coordinate with other distros (and maybe
> > downstreams) so that the new version becomes a standard.
> >
> > Finally, having more than one person on this (to help continuity),
> and a
> > common platform like GitHub also seem very helpful.
> >
> > Paweł
> >
> Agreed in general; the problem is getting it started at all; difficult
> to get other distros to join if there is nothing to join.
>
>
>
A couple of generalisations.

The first solution to unmaintained packages should be to move to an
alternative, if that's possible. Gentoo does not have the resource
to be upstream for very much for the entire Linux community, a point
already made by others.

In volunteer groups things get done by those who want to do them.
Others join later. I think the quote I'm looking for is "Build it and they
will come".

--
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Idea for a new project: gentoo-libs

Jonas Stein
In reply to this post by Marty E. Plummer
On 2018-06-23 04:57, Marty E. Plummer wrote:

> On Fri, Jun 22, 2018 at 09:50:50PM -0500, Marty E. Plummer wrote:
>> So, as you may be aware I've been doing some work on moving bzip2 to an
>> autotools based build. Recently I've ran into app-crypt/mhash, which is
>> in a semi-abandoned state (talking with the maintainer on twitter atm),
>> and I was thinking it may be a good idea to set up a project for keeping
>> these semi-abandoned and really-abandoned libraries and projects up to
>> date and such.
>>
>> Basically, an upstream for packages who's upstream is either
>> uncontactable or is otherwise not accepting bug fixes and patches. So
>> far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
>> there are others in this state.
>>
> Or... call it proxy-upstream, to be in line with the current proxy-maint
> setup?
Please do not call it proxy-*.
The invented word proxymaintainer and proxiedmaintainer are not usefull.
They get always mixed, and are not understood outside of Gentoo.
assistant developer or trainee developer would have been much more useful.

Beside the naming I like the idea, that you want to take care for all
abandoned libs.

Please note, that you can not generate more manpower by creating a
project. In 2015 I calculated

=====================================================

 (Number of developers) / (Number of Projects) < 1.4

=====================================================

Which explains, why most projects today are run by mostly one active person.

If you find an important library, where upstream is dead, fork it and
take responsibility for it.

It makes no sense to make a pool of dead and important software and
delegate the responsibility to a team where nobody really knows the
software.

Better pick a library, communicate with maintainers of the other
distributions and fork it. Keep the library alive in the fork.

It is important for the security to let dead projects die.

--
Best,
Jonas


signature.asc (1000 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Idea for a new project: gentoo-libs

Kent Fredric-2
In reply to this post by Marty E. Plummer
On Fri, 22 Jun 2018 21:50:50 -0500
"Marty E. Plummer" <[hidden email]> wrote:

> So, as you may be aware I've been doing some work on moving bzip2 to an
> autotools based build. Recently I've ran into app-crypt/mhash, which is
> in a semi-abandoned state (talking with the maintainer on twitter atm),
> and I was thinking it may be a good idea to set up a project for keeping
> these semi-abandoned and really-abandoned libraries and projects up to
> date and such.
>
> Basically, an upstream for packages who's upstream is either
> uncontactable or is otherwise not accepting bug fixes and patches. So
> far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
> there are others in this state.
It may be worth mentioning that myself and a handful of others are
kicking around the idea of creating a "vendorised upstream", which
essentially treats all upstreams as unmaintained, and acts as a middle
ground between upstream and linux distributions/end users, by
re-shipping upstreams code with fixes, in a format similar to
upstreams, but with the mentality of a Linux Vendor.

Changes to this project would of course be made under the assumption
that upstream would one day wake up, and may be interested in adopting
some or all of our fixes ( and for upstreams that are currently not
actually dead, this may happen sooner than later )

Presently, this is limited in scope to vendorizing CPAN, but it may
grow.

In concept, this is of course much more work than your idea, but it has
a few advantages, particularly with regards to integrating various
vendors patches in a single place.

But obviously, such a project is somewhat gargantuan, and getting the
working concept off the ground is going to take a while :)

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Idea for a new project: gentoo-libs

Hanno Böck-3
In reply to this post by Marty E. Plummer
On Fri, 22 Jun 2018 21:50:50 -0500
"Marty E. Plummer" <[hidden email]> wrote:

> So, as you may be aware I've been doing some work on moving bzip2 to
> an autotools based build. Recently I've ran into app-crypt/mhash,
> which is in a semi-abandoned state (talking with the maintainer on
> twitter atm), and I was thinking it may be a good idea to set up a
> project for keeping these semi-abandoned and really-abandoned
> libraries and projects up to date and such.

This is a common problem, however if you want to make this reasonable
you wouldn't make it a gentoo thing, but a cross-distro effort. The
idea has been tossed around a lot, but noone yet started implementing
it.

However keeping things alive may not always be the right option.
There's a reason mcrypt is abandoned. It's an ancient crypto library,
crypto is moving forward, there are better options. THe main user of
mcrypt was PHP, and PHP is abandoning it with 7.2. (There are 2 other
users in the gentoo tree of libmcrypt, which are both rather obscure
packages - nsca and elettra.)

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

mail/jabber: [hidden email]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

Reply | Threaded
Open this post in threaded view
|

Re: Idea for a new project: gentoo-libs

Marty E. Plummer
On Mon, Jun 25, 2018 at 07:59:47AM +0200, Hanno Böck wrote:

> On Fri, 22 Jun 2018 21:50:50 -0500
> "Marty E. Plummer" <[hidden email]> wrote:
>
> > So, as you may be aware I've been doing some work on moving bzip2 to
> > an autotools based build. Recently I've ran into app-crypt/mhash,
> > which is in a semi-abandoned state (talking with the maintainer on
> > twitter atm), and I was thinking it may be a good idea to set up a
> > project for keeping these semi-abandoned and really-abandoned
> > libraries and projects up to date and such.
>
> This is a common problem, however if you want to make this reasonable
> you wouldn't make it a gentoo thing, but a cross-distro effort. The
> idea has been tossed around a lot, but noone yet started implementing
> it.
>
> However keeping things alive may not always be the right option.
> There's a reason mcrypt is abandoned. It's an ancient crypto library,
mhash, not mcrypt. I've not loked at mcrypt at all yet, so I have no
ideas as to its status.

> crypto is moving forward, there are better options. THe main user of
> mcrypt was PHP, and PHP is abandoning it with 7.2. (There are 2 other
> users in the gentoo tree of libmcrypt, which are both rather obscure
> packages - nsca and elettra.)
>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: [hidden email]
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
>

Reply | Threaded
Open this post in threaded view
|

mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)

Andrew Savchenko
In reply to this post by Hanno Böck-3
On Mon, 25 Jun 2018 07:59:47 +0200 Hanno Böck wrote:

> On Fri, 22 Jun 2018 21:50:50 -0500
> "Marty E. Plummer" <[hidden email]> wrote:
>
> > So, as you may be aware I've been doing some work on moving bzip2 to
> > an autotools based build. Recently I've ran into app-crypt/mhash,
> > which is in a semi-abandoned state (talking with the maintainer on
> > twitter atm), and I was thinking it may be a good idea to set up a
> > project for keeping these semi-abandoned and really-abandoned
> > libraries and projects up to date and such.
>
> This is a common problem, however if you want to make this reasonable
> you wouldn't make it a gentoo thing, but a cross-distro effort. The
> idea has been tossed around a lot, but noone yet started implementing
> it.
>
> However keeping things alive may not always be the right option.
> There's a reason mcrypt is abandoned. It's an ancient crypto library,
> crypto is moving forward, there are better options.
Do you have any evidence that mcrypt should not be used?

Symmetric cryptography is quite conservative and it took years and
even decades for algorithms and their implementations to become
trusted, so there is nothing wrong in using good old verified
software.

Actually for local symmetric encryption this is the best tool I
know.

Best regards,
Andrew Savchenko

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: mcrypt status

Martin Vaeth-2
Andrew Savchenko <[hidden email]> wrote:
>
> Actually for local symmetric encryption this is the best tool I
> know.

What is the advantage over gpg --symmetric?


Reply | Threaded
Open this post in threaded view
|

Re: mcrypt status

Andrew Savchenko
On Sat, 4 Aug 2018 09:51:14 +0000 (UTC) Martin Vaeth wrote:
> Andrew Savchenko <[hidden email]> wrote:
> >
> > Actually for local symmetric encryption this is the best tool I
> > know.
>
> What is the advantage over gpg --symmetric?

1) mcrypt has wider range of algorithms, including gost which I
need.
2) gpg-agent sometimes causes too much trouble (by being enforced
in gpg2) and I like it more to enter passphares without any agents.
xterm can grab screen and that is sufficient for my needs.

Other than that gpg -s in nice and good tool.

Best regards,
Andrew Savchenko

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)

Hanno Böck-3
In reply to this post by Andrew Savchenko
Hi,

On Sat, 4 Aug 2018 11:43:28 +0300
Andrew Savchenko <[hidden email]> wrote:

> Do you have any evidence that mcrypt should not be used?

Well, PHP was as far as I'm aware its main user and PHP has declared
mcrypt support to be deprecated a while ago.

> Symmetric cryptography is quite conservative and it took years and
> even decades for algorithms and their implementations to become
> trusted, so there is nothing wrong in using good old verified
> software.

When it comes to cipher modes the fact that people use decades old
modes is a problem. See efail for a prominent example, but there
are many less prominent ones.

Look at the mcrypt webpage:
http://mcrypt.sourceforge.net/

Modes of Operation:

CBC
CFB
CTR
ECB
OFB
NCFB

That is a mixture of very insecure (ECB), insecure in most situations
(all others) and totally obscure modes. It doesn't include any
authenticated encryption modes, which in most situations is what you
want to use.

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

mail/jabber: [hidden email]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)

Thomas Deutschmann
On 2018-08-04 16:29, Hanno Böck wrote:
>> Do you have any evidence that mcrypt should not be used?
> Well, PHP was as far as I'm aware its main user and PHP has declared
> mcrypt support to be deprecated a while ago.

In all fairness:

Yes, PHP project has removed ext/mcrypt from core, but they only
moved it into an own PECL extension. My point here is, that they
did not drop and prune mcrypt from universe due to security
vulnerabilities.

Anyone interested in this should read the following posting [1].

tl;dr
Like most crypto libs, mcrypt isn't easy to use and you will
likely do something wrong. In favor of a better solutions which
should prevent such a misuse, mcrypt was deprecated.


See also:
=========
[1] https://why-cant-we-have-nice-things.mwl.be/requests/deprecate-then-remove-mcrypt.


--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


signature.asc (1000 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)

Marty E. Plummer
In reply to this post by Andrew Savchenko
On Sat, Aug 04, 2018 at 11:43:28AM +0300, Andrew Savchenko wrote:

> On Mon, 25 Jun 2018 07:59:47 +0200 Hanno Böck wrote:
> > On Fri, 22 Jun 2018 21:50:50 -0500
> > "Marty E. Plummer" <[hidden email]> wrote:
> >
> > > So, as you may be aware I've been doing some work on moving bzip2 to
> > > an autotools based build. Recently I've ran into app-crypt/mhash,
> > > which is in a semi-abandoned state (talking with the maintainer on
> > > twitter atm), and I was thinking it may be a good idea to set up a
> > > project for keeping these semi-abandoned and really-abandoned
> > > libraries and projects up to date and such.
> >
> > This is a common problem, however if you want to make this reasonable
> > you wouldn't make it a gentoo thing, but a cross-distro effort. The
> > idea has been tossed around a lot, but noone yet started implementing
> > it.
> >
> > However keeping things alive may not always be the right option.
> > There's a reason mcrypt is abandoned. It's an ancient crypto library,
> > crypto is moving forward, there are better options.
>
> Do you have any evidence that mcrypt should not be used?
>
> Symmetric cryptography is quite conservative and it took years and
> even decades for algorithms and their implementations to become
> trusted, so there is nothing wrong in using good old verified
> software.
>
> Actually for local symmetric encryption this is the best tool I
> know.
>
> Best regards,
> Andrew Savchenko
It seems that every last person commenting on this is talking mcrypt,
not mhash, which is what I mentioned in the first place. As far as I can
tell, these are entirely differnt projects which just happen to have a
similar name.


12