On 4/7/12 10:33 PM, Ryan Schmidt wrote:
On Apr 8, 2012, at 00:23, Blair Zajac wrote:
On 04/07/2012 10:04 PM, Ryan Schmidt wrote:
On Apr 6, 2012, at 08:33, Arno Hautala wrote:
On 2012-04-06, Clemens Lang wrote:
We're documenting two hash algorithms that are "blessed". All others are
dep
On Apr 8, 2012, at 00:49, Blair Zajac wrote:
> On 4/7/12 10:28 PM, Jeremy Lavergne wrote:
>>> I don't know why we're so focused on removing md5 support.
>>
>> We're not officially about removing md5, unless it's used alone. We're
>> really about ensuring more than one hash is used.
>
> Ryan se
On 4/7/12 10:28 PM, Jeremy Lavergne wrote:
I don't know why we're so focused on removing md5 support.
We're not officially about removing md5, unless it's used alone. We're really
about ensuring more than one hash is used.
Ryan seems to want to remove it :)
Blair
__
> I update a port's version, download the new distfile, compute the checksums,
> verify the port builds and looks somewhat sane, and commit it. The checksums
> are there to ensure anyone else who tries to install the port gets the same
> distfile I got.
I do this as well :-) I rely on the build
On Apr 8, 2012, at 00:23, Blair Zajac wrote:
> On 04/07/2012 10:04 PM, Ryan Schmidt wrote:
>>
>> On Apr 6, 2012, at 08:33, Arno Hautala wrote:
>>
>>> On 2012-04-06, Clemens Lang wrote:
We're documenting two hash algorithms that are "blessed". All others are
deprecated.
>>>
>>>
> I don't know why we're so focused on removing md5 support.
We're not officially about removing md5, unless it's used alone. We're really
about ensuring more than one hash is used.
> I was thinking why I'm resistant to removing md5 support and it comes down to
> make it easier for somebody to
On 04/07/2012 10:04 PM, Ryan Schmidt wrote:
On Apr 6, 2012, at 08:33, Arno Hautala wrote:
On 2012-04-06, Clemens Lang wrote:
We're documenting two hash algorithms that are "blessed". All others are
deprecated.
Is there an effort to remove the deprecated algorithms? Or a date /
version for
On Apr 6, 2012, at 08:24, Craig Treleaven wrote:
> Hadn't thought about malicious alteration of the distfiles. I presumed it
> was to detect garbled transmission.
It's for both reasons.
___
macports-dev mailing list
macports-dev@lists.macosforge.or
On Apr 6, 2012, at 08:33, Arno Hautala wrote:
> On 2012-04-06, Clemens Lang wrote:
>>
>> We're documenting two hash algorithms that are "blessed". All others are
>> deprecated.
>
> Is there an effort to remove the deprecated algorithms? Or a date /
> version for support to be removed? Just cur
On 2012-04-06, Joshua Root wrote:
> On 2012-4-6 23:33 , Arno Hautala wrote:
>> Is there an effort to remove the deprecated algorithms? Or a date /
>> version for support to be removed? Just curious.
>
> Only md5 is really deprecated, and then only when used by itself. There
> should probably be a
On 2012-4-6 23:33 , Arno Hautala wrote:
> Is there an effort to remove the deprecated algorithms? Or a date /
> version for support to be removed? Just curious.
Only md5 is really deprecated, and then only when used by itself. There
should probably be a lint warning for that.
- Josh
_
> OK, OK, I get it, I'm sorry, please stop the beatings! ;-)
>
> Today I learned; thanks.
We all hit reply at the same time :-)
smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http
> On 2012-4-6 23:07 , Arno Hautala wrote:
>
> I don't think MacPorts actually verifies every hash that is provided
> in the Portfile.
On 2012-04-06, Joshua Root wrote:
>
> It does.
On 2012-04-06, Clemens Lang wrote:
>
> It does verify every checksum the Portfile provides.
On 2012-04-06, Jeremy
> I'm not trying to pick a scab. Just found it curious when I was working on a
> portfile that both were recommended without offering any reasons why.
>
> Hadn't thought about malicious alteration of the distfiles. I presumed it
> was to detect garbled transmission.
If Ryan were awake already
At 7:56 AM -0500 4/6/12, Jeremy Lavergne wrote:
> Just curious, why two checkums? Is one not sufficient?
Here we go again :-)
I'm not trying to pick a scab. Just found it curious when I was
working on a portfile that both were recommended without offering any
reasons why.
Hadn't though
> I typically just use whatever I get when doing port -d and copy and paste the
> checksum from there. Since I did that and still got a suggestion to change
> the hash, can this output be modified to reflect what's wanted/needed as
> hashes?
MacPorts will print out the expected hashes (with -v
hashes I could then just include them in the port as checksums
> rather than the md5, sha1, and rmd160.
>
> openssl sha256 path/to/file
> openssl rmd160 path/to/file
It's fine to use whatever upstream provides, just try to use more than
one hash type, especially if one of them is
I got a message about this too in my latest port (pidgin)
I typically just use whatever I get when doing port -d and copy and paste
the checksum from there. Since I did that and still got a suggestion to
change the hash, can this output be modified to reflect what's
wanted/needed as hashes?
On
as checksums rather than the md5,
> sha1, and rmd160.
>
> openssl sha256 path/to/file
> openssl rmd160 path/to/file
It's much easier to put what checksums you're after in the Portfile and letting
MacPorts tell you how they should be set:
* place checksums md5 a\ sha1 b\
> One thought would be that while one hash algorithm may exhibit a flaw
> that allows arbitrary changes to the payload without altering the
> hash, it's extremely unlikely that two hashes would be affected in the
> same way.
This is the main reason we have more than one hash: it's possible to have
On Fri, Apr 06, 2012 at 09:07:49AM -0400, Arno Hautala wrote:
> I don't think MacPorts actually verifies every hash that is provided
> in the Portfile.
It does verify every checksum the Portfile provides.
> I think the actual reason is to provide a backup hash if the first
> algorithm isn't avail
On 2012-4-6 23:07 , Arno Hautala wrote:
> On 2012-04-06, Craig Treleaven wrote:
>>
>> Just curious, why two checkums? Is one not sufficient?
>
> One thought would be that while one hash algorithm may exhibit a flaw
> that allows arbitrary changes to the payload without altering the
> hash, it's
than the md5, sha1, and rmd160.
openssl sha256 path/to/file
openssl rmd160 path/to/file
On Fri, Apr 6, 2012 at 7:58 AM, Arno Hautala wrote:
> On 2012-04-06, Blair Zajac wrote:
> > On 4/5/12 9:53 PM, Arno Hautala wrote:
> >>
> >> Also, I think md5 in Portfiles is depre
On 2012-04-06, Craig Treleaven wrote:
>
> Just curious, why two checkums? Is one not sufficient?
One thought would be that while one hash algorithm may exhibit a flaw
that allows arbitrary changes to the payload without altering the
hash, it's extremely unlikely that two hashes would be affected
On 2012-04-06, Blair Zajac wrote:
> On 4/5/12 9:53 PM, Arno Hautala wrote:
>>
>> Also, I think md5 in Portfiles is deprecated. The preferred hashes are
>> rmd160 and sha256.
>
> If upstream provides a md5, I like to use it, as it makes double checking
> the
> port easier.
MacPorts is trying to ph
I had looked at the guide and didn't understand at first what I saw. I see
the openssl solution in point #13 staring me in the face. Yikes. The
checksum addition to the port command will be interesting to try as well.
Thank you
On Fri, Apr 6, 2012 at 7:50 AM, Craig Treleaven wrote:
> At 11:54 PM
> Just curious, why two checkums? Is one not sufficient?
Here we go again :-)
smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macpo
At 11:54 PM -0500 4/5/12, Ryan Schmidt wrote:
On Apr 5, 2012, at 23:53, Arno Hautala wrote:
The preferred hashes are
rmd160 and sha256.
Right. The simplest way to generate them is to remove the checksum
lines from the Portfile (or insert invalid rmd160 and sha256
checksums into the Portfi
On 4/5/12 9:53 PM, Arno Hautala wrote:
On Fri, Apr 6, 2012 at 00:15, M. Daniel Becque wrote:
I'm working on upgrading the port of Proftpd from 1.3.3c to 1.3.3g as a
first step. From the binary file repository i see where the md5 # comes
from but how do you get the sha1 and rmd160 numbe
On 4/5/12 9:15 PM, M. Daniel Becque wrote:
I'm working on upgrading the port of Proftpd from 1.3.3c to 1.3.3g as a first
step. From the binary file repository i see where the md5 # comes from but how
do you get the sha1 and rmd160 numbers to place in the port file? There is
another file
On Apr 5, 2012, at 23:53, Arno Hautala wrote:
> The preferred hashes are
> rmd160 and sha256.
Right. The simplest way to generate them is to remove the checksum lines from
the Portfile (or insert invalid rmd160 and sha256 checksums into the Portfile),
then run "sudo port -d checksum"; MacPorts
On Fri, Apr 6, 2012 at 00:15, M. Daniel Becque wrote:
> I'm working on upgrading the port of Proftpd from 1.3.3c to 1.3.3g as a
> first step. From the binary file repository i see where the md5 # comes
> from but how do you get the sha1 and rmd160 numbers to place in the port
&g
I'm working on upgrading the port of Proftpd from 1.3.3c to 1.3.3g as a
first step. From the binary file repository i see where the md5 # comes
from but how do you get the sha1 and rmd160 numbers to place in the port
file? There is another file with each release, .asc, in the repository.
T
33 matches
Mail list logo
