Puppet users - May 2011 - changing the default key length and hash

Hi all,

I would like to start a discussion about changing the default key length
From 1024 bits to 2048, and am interested to know if this might cause
any issues for people. 

puppet.conf(5) says that the keylength parameter defaults to 1024 bits
for new RSA keys.

There are many reasons why 1024bits is just not good enough now days:

 . many free software crypto tools are defaulting to 2048-bit keys now
 (e.g. OpenSSH, GnuPG)

 . NIST has recommended avoiding reliance on 1024-bit keys after the end
 of 2010

you can compare other comparable standards at http://keylength.com/

Considering that generated certificates are expected to be around for at
least the lifetime of the server itself, setting a reasonable bit-length
key from the beginning is pretty important, especially if the server
might be expected to be around for some years from now…

Not only is the default keylength for the CA 1024 bits, the default hash
is MD5.

The german BSI1 produces a yearly document[0] that defines which
algorithms should be save for usage over the next five years. This
document rules out MD5, SHA-1 and RIPEMD-160 for hashing and key sizes <
1976 bits for RSA keys right now.

Now that we are well beyond the NIST recommendation, this seems to be a
bug, and I filed it as such[1]. However, I''m throwing this out there to
see if this might be an issue for anyone, such as on older
distributions.

discuss!
micah


0.
http://www.bundesnetzagentur.de/cae/servlet/contentblob/192414/publicationFile/10008/2011AlgoKatpdf.pdf
0. https://projects.puppetlabs.com/issues/6663


--

Hi Micah,

In short, I''m in agreement with you. With the CA which is defaulted to
5 years (not at all surprising) there''s no doubt that soon (maybe 2.7
is a good time?) that 2048 key size should be used for at least the CA key, if
not default for client key generation as well. Secondly, yes, I don''t
know why MD5 would be the hashing algorithm of choice in this case either.

As I recall last year, most major root CAs went to 2048 last year to not anger
the NIST recommendation.

-Mark

On May 19, 2011, at 11:07 PM, Micah Anderson wrote:
> 
> Hi all,
> 
> I would like to start a discussion about changing the default key length
> From 1024 bits to 2048, and am interested to know if this might cause
> any issues for people. 
> 
> puppet.conf(5) says that the keylength parameter defaults to 1024 bits
> for new RSA keys.
> 
> There are many reasons why 1024bits is just not good enough now days:
> 
> . many free software crypto tools are defaulting to 2048-bit keys now
> (e.g. OpenSSH, GnuPG)
> 
> . NIST has recommended avoiding reliance on 1024-bit keys after the end
> of 2010
> 
> you can compare other comparable standards at http://keylength.com/
> 
> Considering that generated certificates are expected to be around for at
> least the lifetime of the server itself, setting a reasonable bit-length
> key from the beginning is pretty important, especially if the server
> might be expected to be around for some years from now…
> 
> Not only is the default keylength for the CA 1024 bits, the default hash
> is MD5.
> 
> The german BSI1 produces a yearly document[0] that defines which
> algorithms should be save for usage over the next five years. This
> document rules out MD5, SHA-1 and RIPEMD-160 for hashing and key sizes <
> 1976 bits for RSA keys right now.
> 
> Now that we are well beyond the NIST recommendation, this seems to be a
> bug, and I filed it as such[1]. However, I''m throwing this out
there to
> see if this might be an issue for anyone, such as on older
> distributions.
> 
> discuss!
> micah
> 
> 
> 0.
http://www.bundesnetzagentur.de/cae/servlet/contentblob/192414/publicationFile/10008/2011AlgoKatpdf.pdf
> 0. https://projects.puppetlabs.com/issues/6663
> 
> 
> -- 
> 
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Fri, May 20, 2011 at 5:39 AM, Mark Stanislav
<mark.stanislav@gmail.com>wrote:
> Hi Micah,
>
> In short, I''m in agreement with you. With the CA which is
defaulted to 5
> years (not at all surprising) there''s no doubt that soon (maybe
2.7 is a
> good time?) that 2048 key size should be used for at least the CA key, if
> not default for client key generation as well. Secondly, yes, I
don''t know
> why MD5 would be the hashing algorithm of choice in this case either.
>
> As I recall last year, most major root CAs went to 2048 last year to not
> anger the NIST recommendation.
>
We will do this for 2.7.x unless we get major pushback from the community.


>
> -Mark
>
> On May 19, 2011, at 11:07 PM, Micah Anderson wrote:
>
> >
> > Hi all,
> >
> > I would like to start a discussion about changing the default key
length
> > From 1024 bits to 2048, and am interested to know if this might cause
> > any issues for people.
> >
> > puppet.conf(5) says that the keylength parameter defaults to 1024 bits
> > for new RSA keys.
> >
> > There are many reasons why 1024bits is just not good enough now days:
> >
> > . many free software crypto tools are defaulting to 2048-bit keys now
> > (e.g. OpenSSH, GnuPG)
> >
> > . NIST has recommended avoiding reliance on 1024-bit keys after the
end
> > of 2010
> >
> > you can compare other comparable standards at http://keylength.com/
> >
> > Considering that generated certificates are expected to be around for
at
> > least the lifetime of the server itself, setting a reasonable
bit-length
> > key from the beginning is pretty important, especially if the server
> > might be expected to be around for some years from now…
> >
> > Not only is the default keylength for the CA 1024 bits, the default
hash
> > is MD5.
> >
> > The german BSI1 produces a yearly document[0] that defines which
> > algorithms should be save for usage over the next five years. This
> > document rules out MD5, SHA-1 and RIPEMD-160 for hashing and key sizes
<
> > 1976 bits for RSA keys right now.
> >
> > Now that we are well beyond the NIST recommendation, this seems to be
a
> > bug, and I filed it as such[1]. However, I''m throwing this
out there to
> > see if this might be an issue for anyone, such as on older
> > distributions.
> >
> > discuss!
> > micah
> >
> >
> > 0.
>
http://www.bundesnetzagentur.de/cae/servlet/contentblob/192414/publicationFile/10008/2011AlgoKatpdf.pdf
> > 0. https://projects.puppetlabs.com/issues/6663
> >
> >
> > --
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

-- 
Nigel Kersten
Product, Puppet Labs
@nigelkersten

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Fri, May 20, 2011 at 08:23, Nigel Kersten <nigel@puppetlabs.com>
wrote:
> On Fri, May 20, 2011 at 5:39 AM, Mark Stanislav
<mark.stanislav@gmail.com>
> wrote:
>>
>> In short, I''m in agreement with you. With the CA which is
defaulted to 5
>> years (not at all surprising) there''s no doubt that soon
(maybe 2.7 is a
>> good time?) that 2048 key size should be used for at least the CA key,
if
>> not default for client key generation as well. Secondly, yes, I
don''t know
>> why MD5 would be the hashing algorithm of choice in this case either.
>>
>> As I recall last year, most major root CAs went to 2048 last year to
not
>> anger the NIST recommendation.
>
> We will do this for 2.7.x unless we get major pushback from the community.
To replicate what I said in RedMine:

I am strongly of the view that we should follow the most restrictive
of the current sets of government advice (eg: BSI, NSA/NIST, etc) and
advice from the experts in the field. If this requires addressing the
question of how to achieve compatibility then we had better solve
this, before someone genuinely breaks MD5, or RSA, or whatever in a
way that matters to us, and we end up in more serious trouble: having
to solve this in zero time, rather than with the relatively luxury of
time.

Larger keys, better hashing (probably by adding them as well as md5,
rather than just replacing it, etc.)

(Oh, and we absolutely have the capabilities to inspect the client
version and make intelligent decisions about what we ship in terms of
checksums, etc, as part of our compatibility story. As long as the
master leads the agent in version we should be fine.)

Daniel
-- 
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman <daniel@puppetlabs.com>
✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
♲ Made with 100 percent post-consumer electrons

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On May 24, 2011, at 1:38 AM, Daniel Pittman wrote:
> On Fri, May 20, 2011 at 08:23, Nigel Kersten <nigel@puppetlabs.com>
wrote:
>> On Fri, May 20, 2011 at 5:39 AM, Mark Stanislav
<mark.stanislav@gmail.com>
>> wrote:
>>> 
>>> In short, I''m in agreement with you. With the CA which is
defaulted to 5
>>> years (not at all surprising) there''s no doubt that soon
(maybe 2.7 is a
>>> good time?) that 2048 key size should be used for at least the CA
key, if
>>> not default for client key generation as well. Secondly, yes, I
don''t know
>>> why MD5 would be the hashing algorithm of choice in this case
either.
>>> 
>>> As I recall last year, most major root CAs went to 2048 last year
to not
>>> anger the NIST recommendation.
>> 
>> We will do this for 2.7.x unless we get major pushback from the
community.
> 
> To replicate what I said in RedMine:
For those playing along at home ;) 
http://projects.puppetlabs.com/issues/6663
> I am strongly of the view that we should follow the most restrictive
> of the current sets of government advice (eg: BSI, NSA/NIST, etc) and
> advice from the experts in the field. If this requires addressing the
> question of how to achieve compatibility then we had better solve
> this, before someone genuinely breaks MD5, or RSA, or whatever in a
> way that matters to us, and we end up in more serious trouble: having
> to solve this in zero time, rather than with the relatively luxury of
> time.
There will of course be a trade-off for security versus performance, which is
why being reasonable about strength used should be also considered. 2048 bit RSA
keys are ''good'' until ~2030 at this time (according to NIST).
Considering a default CA cert is five years for Puppet, this is a very
reasonable way to go. There shouldn''t be a compatibility issue to solve
unless there''s some interesting crypto voodoo occurring in Puppet ;)
> 
> Larger keys, better hashing (probably by adding them as well as md5,
> rather than just replacing it, etc.)
I really don''t know of any reason to implement MD5 at all. It *is*
broken and we do have better algorithms to implement. Even if SHA-1 is on its
last leg, it''s still a step-up. SHA-256 is preferred, though.

Again, a great discussion to be having and very forward thinking.

-Mark
> 
> (Oh, and we absolutely have the capabilities to inspect the client
> version and make intelligent decisions about what we ship in terms of
> checksums, etc, as part of our compatibility story. As long as the
> master leads the agent in version we should be fine.)
> 
> Daniel
> -- 
> ⎋ Puppet Labs Developer – http://puppetlabs.com
> ✉ Daniel Pittman <daniel@puppetlabs.com>
> ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
> ♲ Made with 100 percent post-consumer electrons
> 
> -- 
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
> 
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, May 24, 2011 at 06:36, Mark Stanislav <mark.stanislav@gmail.com>
wrote:
> On May 24, 2011, at 1:38 AM, Daniel Pittman wrote:
>> On Fri, May 20, 2011 at 08:23, Nigel Kersten
<nigel@puppetlabs.com> wrote:
>>> On Fri, May 20, 2011 at 5:39 AM, Mark Stanislav
<mark.stanislav@gmail.com>
>>> wrote:
[…]
>> Larger keys, better hashing (probably by adding them as well as md5,
>> rather than just replacing it, etc.)
>
> I really don''t know of any reason to implement MD5 at all. It *is*
broken and we do have better algorithms to implement. Even if SHA-1 is on its
last leg, it''s still a step-up. SHA-256 is preferred, though.
Ah.  We have a policy of supporting at least two major versions back,
and would generally prefer not to have to go and patch all the 2.6 and
2.7 releases out there when 2.8 moves to a more secure hash.  (...or
0.25 and 2.6 when 2.7 adds it. ;)

So, it isn''t a requirement for any reason other than our desire not to
make more work for ourselves than we need to; it would also be good to
get into a mode where we are good at changing the hash; SHA
derivatives won''t last forever either.

Regards,
    Daniel
-- 
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman <daniel@puppetlabs.com>
✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
♲ Made with 100 percent post-consumer electrons

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 24/05/11 19:50, Daniel Pittman wrote:
> On Tue, May 24, 2011 at 06:36, Mark Stanislav
<mark.stanislav@gmail.com> wrote:
>> On May 24, 2011, at 1:38 AM, Daniel Pittman wrote:
>>> On Fri, May 20, 2011 at 08:23, Nigel Kersten
<nigel@puppetlabs.com> wrote:
>>>> On Fri, May 20, 2011 at 5:39 AM, Mark Stanislav
<mark.stanislav@gmail.com>
>>>> wrote:
> […]
>>> Larger keys, better hashing (probably by adding them as well as
md5,
>>> rather than just replacing it, etc.)
>>
>> I really don''t know of any reason to implement MD5 at all. It
*is* broken and we do have better algorithms to implement. Even if SHA-1 is on
its last leg, it''s still a step-up. SHA-256 is preferred, though.
> 
> Ah.  We have a policy of supporting at least two major versions back,
> and would generally prefer not to have to go and patch all the 2.6 and
> 2.7 releases out there when 2.8 moves to a more secure hash.  (...or
> 0.25 and 2.6 when 2.7 adds it. ;)
To my knowledge, Puppet is pretty agnostic regarding certificate
content, as everything is handled by the ruby openssl library.
I mean even though our full PKI is based on a 2048 bits key with
SHA-256, when generating a certificate to a 2.6 or 0.25 client, the
client should be able to accept it without code modification (since the
whole certificate is not handled by puppet).

My question is more what will be the upgrade path from a 1024 bits
certificate PKI to a larger one for our users. Note that I think some
users will soon have CA that will expire. I don''t think we yet have a
canned solution for this specific issue.
-- 
Brice Figureau
My Blog: http://www.masterzen.fr/

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On May 24, 2011, at 1:50 PM, Daniel Pittman wrote:
> On Tue, May 24, 2011 at 06:36, Mark Stanislav
<mark.stanislav@gmail.com> wrote:
>> On May 24, 2011, at 1:38 AM, Daniel Pittman wrote:
>>> On Fri, May 20, 2011 at 08:23, Nigel Kersten
<nigel@puppetlabs.com> wrote:
>>>> On Fri, May 20, 2011 at 5:39 AM, Mark Stanislav
<mark.stanislav@gmail.com>
>>>> wrote:
> […]
>>> Larger keys, better hashing (probably by adding them as well as
md5,
>>> rather than just replacing it, etc.)
>> 
>> I really don''t know of any reason to implement MD5 at all. It
*is* broken and we do have better algorithms to implement. Even if SHA-1 is on
its last leg, it''s still a step-up. SHA-256 is preferred, though.
> 
> Ah.  We have a policy of supporting at least two major versions back,
> and would generally prefer not to have to go and patch all the 2.6 and
> 2.7 releases out there when 2.8 moves to a more secure hash.  (...or
> 0.25 and 2.6 when 2.7 adds it. ;)
I don''t think there should be a compat issue with regard to
certificates as that would be relevant to SSL libraries which should have fully
supported those algorithms for years. I could also be entirely wrong so feel
free to let me know as I''m speaking from a basic crypto perspective and
not with respect to Puppet directly.
> 
> So, it isn''t a requirement for any reason other than our desire
not to
> make more work for ourselves than we need to; it would also be good to
> get into a mode where we are good at changing the hash; SHA
> derivatives won''t last forever either.
NIST is working on the AHS candidates still and the timeline pushes it out until
2013 to likely ''implement'' it as a new standard (at least
formally). SHA 256/384/512 are going to be plenty sustainable for this time
period and the foreseeable future.

-Mark
> 
> Regards,
>    Daniel
> -- 
> ⎋ Puppet Labs Developer – http://puppetlabs.com
> ✉ Daniel Pittman <daniel@puppetlabs.com>
> ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
> ♲ Made with 100 percent post-consumer electrons
> 
> -- 
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
> 
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, May 24, 2011 at 11:02, Mark Stanislav <mark.stanislav@gmail.com>
wrote:
> On May 24, 2011, at 1:50 PM, Daniel Pittman wrote:
>> On Tue, May 24, 2011 at 06:36, Mark Stanislav
<mark.stanislav@gmail.com> wrote:
>>> On May 24, 2011, at 1:38 AM, Daniel Pittman wrote:
>>>> On Fri, May 20, 2011 at 08:23, Nigel Kersten
<nigel@puppetlabs.com> wrote:
>>>>> On Fri, May 20, 2011 at 5:39 AM, Mark Stanislav
<mark.stanislav@gmail.com>
>>>>> wrote:
>> […]
>>>> Larger keys, better hashing (probably by adding them as well as
md5,
>>>> rather than just replacing it, etc.)
>>>
>>> I really don''t know of any reason to implement MD5 at all.
It *is* broken and we do have better algorithms to implement. Even if SHA-1 is
on its last leg, it''s still a step-up. SHA-256 is preferred, though.
>>
>> Ah.  We have a policy of supporting at least two major versions back,
>> and would generally prefer not to have to go and patch all the 2.6 and
>> 2.7 releases out there when 2.8 moves to a more secure hash.  (...or
>> 0.25 and 2.6 when 2.7 adds it. ;)
>
> I don''t think there should be a compat issue with regard to
certificates as that would be relevant to SSL libraries which should have fully
supported those algorithms for years. I could also be entirely wrong so feel
free to let me know as I''m speaking from a basic crypto perspective and
not with respect to Puppet directly.
Ah.  I was thinking in the broader scope of getting us away from
insecure hashes elsewhere in the product.  From a strictly certificate
POV, indeed, it should be just fine.

Daniel
-- 
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman <daniel@puppetlabs.com>
✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
♲ Made with 100 percent post-consumer electrons

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> Ah.  I was thinking in the broader scope of getting us away from
> insecure hashes elsewhere in the product.  From a strictly certificate
> POV, indeed, it should be just fine.
I''m trying to configure FIPS-compliant servers, and I''ve run
into segfaults thrown by the Ruby interpreter when Puppet tries to use MD5. I
think this is a problem somewhere else in my system, not Puppet, but it
highlights the issue that I need Puppet to be able to use other hashing
algorithms in its system configuration work, not merely in its certificates.

I''ve got an internal patch that replaces Digest::MD5 with Digest::SHA2
in puppet/util/checksums.rb and in puppet/parser/functions/md5.rb, but this
method lacks finesse. The DSL function is still called md5, and the string
representation of a file still starts with ''{md5}'' even though
the rest is an SHA256 sum.

It appears that puppet/util/checksums.rb was a start at adding hash algorithm
flexibility, but the ''{md5}'' is added on elsewhere.

Has someone else already done things about this?

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wed, May 25, 2011 at 10:23, Jennings, Jared L CTR USAF AFMC 46
SK/CCI <jared.jennings.ctr@eglin.af.mil> wrote:
>> Ah.  I was thinking in the broader scope of getting us away from
>> insecure hashes elsewhere in the product.  From a strictly certificate
>> POV, indeed, it should be just fine.
>
> I''m trying to configure FIPS-compliant servers, and I''ve
run into segfaults thrown by the Ruby interpreter when Puppet tries to use MD5.
I think this is a problem somewhere else in my system, not Puppet, but it
highlights the issue that I need Puppet to be able to use other hashing
algorithms in its system configuration work, not merely in its certificates.
O_o  At this point I would be pretty worried; that sounds like a nasty
bug, and the worry that it is from some sort of memory corruption that
is going to be making a mess of other things along the way.  That
said, I agree that being able to use a different digest would be
great.
> I''ve got an internal patch that replaces Digest::MD5 with
Digest::SHA2 in puppet/util/checksums.rb and in puppet/parser/functions/md5.rb,
but this method lacks finesse. The DSL function is still called md5, and the
string representation of a file still starts with ''{md5}'' even
though the rest is an SHA256 sum.
Yeah.  You will also hit troubles if you don''t have a uniformly
patched solution out there, or even if...
> It appears that puppet/util/checksums.rb was a start at adding hash
algorithm flexibility, but the ''{md5}'' is added on elsewhere.
...you fixed this, and you needed to run against unpatched clients.
We don''t generically match the checksum at all, so that assumption is
going to be baked into a whole bunch of places.
> Has someone else already done things about this?
Not that we are aware of.  If you delivered support for configuring
that through the product, though, we would almost certainly support it
without any other compatibility support.  (As in, I think it has value
in that form alone, even though we want to support multiple hashes,
etc.)

Daniel
-- 
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman <daniel@puppetlabs.com>
✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
♲ Made with 100 percent post-consumer electrons

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Just noting that we are moving forward on the original ticket.

It does appear that we''ve drifted onto other issues, I''d like
to remind
people to please file bugs/feature requests on those so we don''t lose
track
of them.



On Wed, May 25, 2011 at 12:41 PM, Daniel Pittman
<daniel@puppetlabs.com>wrote:
> On Wed, May 25, 2011 at 10:23, Jennings, Jared L CTR USAF AFMC 46
> SK/CCI <jared.jennings.ctr@eglin.af.mil> wrote:
> >> Ah.  I was thinking in the broader scope of getting us away from
> >> insecure hashes elsewhere in the product.  From a strictly
certificate
> >> POV, indeed, it should be just fine.
> >
> > I''m trying to configure FIPS-compliant servers, and
I''ve run into
> segfaults thrown by the Ruby interpreter when Puppet tries to use MD5. I
> think this is a problem somewhere else in my system, not Puppet, but it
> highlights the issue that I need Puppet to be able to use other hashing
> algorithms in its system configuration work, not merely in its
certificates.
>
> O_o  At this point I would be pretty worried; that sounds like a nasty
> bug, and the worry that it is from some sort of memory corruption that
> is going to be making a mess of other things along the way.  That
> said, I agree that being able to use a different digest would be
> great.
>
> > I''ve got an internal patch that replaces Digest::MD5 with
Digest::SHA2 in
> puppet/util/checksums.rb and in puppet/parser/functions/md5.rb, but this
> method lacks finesse. The DSL function is still called md5, and the string
> representation of a file still starts with ''{md5}'' even
though the rest is
> an SHA256 sum.
>
> Yeah.  You will also hit troubles if you don''t have a uniformly
> patched solution out there, or even if...
>
> > It appears that puppet/util/checksums.rb was a start at adding hash
> algorithm flexibility, but the ''{md5}'' is added on
elsewhere.
>
> ...you fixed this, and you needed to run against unpatched clients.
> We don''t generically match the checksum at all, so that assumption
is
> going to be baked into a whole bunch of places.
>
> > Has someone else already done things about this?
>
> Not that we are aware of.  If you delivered support for configuring
> that through the product, though, we would almost certainly support it
> without any other compatibility support.  (As in, I think it has value
> in that form alone, even though we want to support multiple hashes,
> etc.)
>
> Daniel
> --
> ⎋ Puppet Labs Developer – http://puppetlabs.com
> ✉ Daniel Pittman <daniel@puppetlabs.com>
> ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
> ♲ Made with 100 percent post-consumer electrons
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

-- 
Nigel Kersten
Product, Puppet Labs
@nigelkersten

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.