[ALL] Problems with default download page hash types

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

[ALL] Problems with default download page hash types

sebb-2-2
I have had to fix several download pages recently because they
referred to sha512 instead of sha256.

Please would RMs double-check that the pom has the correct setting and
that the generated download_xyz.xml file corresponds with the file
names?

In future, I think the hash setting should *always* be specified in
the pom, rather than relying on a default (*)
How does one know whether the setting is missing by accident or design?
(It does not help that the default has been changed twice fairly recently)


Sebb.
(*) IMO built-in defaults should only be used for values that are
almost always correct, i.e. where it is unusual to see a different
value. Defaults should never be changed.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Problems with default download page hash types

Matt Sicker
I know it’s policy, but why exactly do we have to provide checksum files
when the asc file is a already a checksum (and most likely based on SHA256
or 512 anyways)?

On Thu, Aug 15, 2019 at 04:03, sebb <[hidden email]> wrote:

> I have had to fix several download pages recently because they
> referred to sha512 instead of sha256.
>
> Please would RMs double-check that the pom has the correct setting and
> that the generated download_xyz.xml file corresponds with the file
> names?
>
> In future, I think the hash setting should *always* be specified in
> the pom, rather than relying on a default (*)
> How does one know whether the setting is missing by accident or design?
> (It does not help that the default has been changed twice fairly recently)
>
>
> Sebb.
> (*) IMO built-in defaults should only be used for values that are
> almost always correct, i.e. where it is unusual to see a different
> value. Defaults should never be changed.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Problems with default download page hash types

sebb-2-2
On Thu, 15 Aug 2019 at 14:50, Matt Sicker <[hidden email]> wrote:
>
> I know it’s policy, but why exactly do we have to provide checksum files
> when the asc file is a already a checksum (and most likely based on SHA256
> or 512 anyways)?

I assume because it's harder to validate a sig; the hash is better than nothing.

> On Thu, Aug 15, 2019 at 04:03, sebb <[hidden email]> wrote:
>
> > I have had to fix several download pages recently because they
> > referred to sha512 instead of sha256.
> >
> > Please would RMs double-check that the pom has the correct setting and
> > that the generated download_xyz.xml file corresponds with the file
> > names?
> >
> > In future, I think the hash setting should *always* be specified in
> > the pom, rather than relying on a default (*)
> > How does one know whether the setting is missing by accident or design?
> > (It does not help that the default has been changed twice fairly recently)
> >
> >
> > Sebb.
> > (*) IMO built-in defaults should only be used for values that are
> > almost always correct, i.e. where it is unusual to see a different
> > value. Defaults should never be changed.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> > --
> Matt Sicker <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]