All --
IMO ( and ITO of other SBo Customers ), The MD5SUM= field in the .info file
is to verify that the DOWNLOAD= files that you downloaded the same files
that the Maintainer downloaded.
Nothing more than that.
It is not for security -- the SBo Maintainer cannot guarantee that the
source files
24 Αυγ 2018, 2:03 μμ, ο χρήστης «t...@airmail.cc» έγραψε:
> Do you really want to wait until it becomes practical *and* published?
There is no ending to security measures. You stop to take measures when they’re
is no threat, not possibility of threat.
1. Crackers are not stupid to waste time to
However, you absolutely cannot assume that because the MD5 sum matches
that the file is in any way "safe" or was not tampered with /before/
the maintainer got to it.
Can I assume that because MD5 sum matches that the file was not tampered
after the maintainer got it? I believe this was the ori
On Thu, 23 Aug 2018, Erik Hanson wrote:
On 8/23/18 5:59 PM, t...@airmail.cc wrote:
So, one can verify the authenticity of the SlackBuild script, but the
authenticity of the source tarball itself used by the aforementioned
script is uncertain? If that's the case then why would one bother with
ve
On 8/23/18 5:59 PM, t...@airmail.cc wrote:
> So, one can verify the authenticity of the SlackBuild script, but the
> authenticity of the source tarball itself used by the aforementioned
> script is uncertain? If that's the case then why would one bother with
> verifying authenticity at all? (Somet
On Fri, Aug 24, 2018 at 01:59:59AM +0300, t...@airmail.cc wrote:
> >What are all of those .asc files in the repository?
> >
> >Those files are GPG signatures. They can be used to verify that the
> >SlackBuild script tarball is exactly the one that we placed on the site.
>
> So, one can verify the
On Fri, 2018-08-24 at 01:59 +0300, t...@airmail.cc wrote:
> > > > Each SlackBuild archive is signed by the SBo devs, so any
> > > > modifications on the server (or in-between) would fail
> > > > subsequent
> > > > verification. In that case it's the GPG signature that you
> > > > trust to
> > > > v
Each SlackBuild archive is signed by the SBo devs, so any
modifications on the server (or in-between) would fail subsequent
verification. In that case it's the GPG signature that you trust to
verify the .info file contents (and all the rest of the SlackBuild
stuff), not the MD5 sum or whatever els
Hello,
I think this is not a big deal, changing to another hash function should be
easy enough.
But I also think slackbuilds should stay away of the security discussion.
Providing a secure distribution channel is in the hands of the code owner only.
If the source is already weak there is no en
On Thu, Aug 23, 2018 at 01:45:44AM -0400, T3 slider wrote:
> On Wed, Aug 22, 2018, 11:15 PM David O'Shaughnessy wrote:
>
> > For an attacker to change the upstream source archive without
> > changing the MD5 requires a 2nd preimage attack, which as far as
> > I understand is not computationally f
On 08/23/2018 03:45 PM, T3 slider wrote:
> The download files do not necessarily have to be tar archives, and in
> some cases (generally those with multiple download files and therefore
> multiple checksums), individual files can be included for download.
> Intentional PDF collisions have been arou
On Wed, Aug 22, 2018, 11:15 PM David O'Shaughnessy wrote:
> For an
> attacker to change the upstream source archive without changing the MD5
> requires a 2nd preimage attack, which as far as I understand is not
> computationally feasible at present. This is different to a much simpler
> collision
On 08/23/2018 12:55 AM, t...@airmail.cc wrote:
> Sorry, the question I had in mind was about MD5 sums inside it. Seems
> kind of strange that SlackBuild archive is protected by GPG signature,
> but the actual source tarball is not signed and is protected by
> (obsolete) MD5 checksum. Aren't this si
On 8/22/18 9:55 AM, t...@airmail.cc wrote:
>> Each SlackBuild archive is signed by the SBo devs, so any
>> modifications on the server (or in-between) would fail subsequent
>> verification. In that case it's the GPG signature that you trust to
>> verify the .info file contents (and all the rest of
On 22/08/2018 15:55, t...@airmail.cc wrote:
Each SlackBuild archive is signed by the SBo devs, so any
modifications on the server (or in-between) would fail subsequent
verification. In that case it's the GPG signature that you trust to
verify the .info file contents (and all the rest of the S
Each SlackBuild archive is signed by the SBo devs, so any modifications
on the server (or in-between) would fail subsequent verification. In
that case it's the GPG signature that you trust to verify the .info
file contents (and all the rest of the SlackBuild stuff), not the MD5
sum or whatever
On 08/21/2018 09:32 PM, t...@airmail.cc wrote:
> Hello.
>
> I have a question about DOWNLOAD and MD5SUM variables in the
> .info files.
>
> As this page https://www.gnupg.org/faq/weak-digest-algos.html states:
>
>> It is better to entirely avoid the MD5 algorithm and don't put any
>> value in si
17 matches
Mail list logo
