Re: [Slackbuilds-users] MD5 hash sums

[Habs]

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
verifying authenticity at all? (Something authentic) x (Something that
may or may not be authentic) == (Something that may or may not be
authentic), right?


It's been mentioned in this thread enough times that MD5 has not fallen
to the attack you think it has, so I won't repeat that talking point,
but I will try and clarify something..

The checksums are not there to verify authenticity. Everyone seems to be
putting far too much stock in the MD5 sums in the .info files. I can't
stress this enough: they're not there for security.

You could almost think of it as a version number. If the file you
download matches the MD5 sum provided, then you know it's the same file
the maintainer used, and the same file the SlackBuild was tested against
by a SlackBuilds.org admin. This helps to ensure the SlackBuild will
work as intended, creating a valid package.

What the MD5 sum can, and does do on a regular basis, is raise a red
flag when it mismatches. Possibly the source has gone missing, or been
replaced by upstream without a change to the file name. These things
happen often enough that it's important we have a checksum, and that
people use it rather than complain that a SlackBuild is broken.

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. Auditing or policing upstream sources is far
beyond the scope of this project. We could use the strongest hashing
algorithm available, but telling people it's a mark of authenticity
would be nothing but theater.


--
Erik




It seems clear enough to me and has done since it was explained to me a
while back.

Effectively, if the maintainer unfortunately has used an 'unsafe' source, 
created its checksum for that source and then uploaded the build package, 
then all the checksum is doing when use it, is validating it was that 
original unsafe source (assuming it hasn't again been altered); or more 
preferably and likely the 'safe' source - as said, there is nothing SBo 
can do about unsafe sources and updating to better checksums etc won't 
help that it seems to me.


I think the current approach is 'safe enough' once one accepts the above
to prove nothing was tampered with when we get it - or at least will let
us know.

I stand to be corrected, however.

Habs

--- Sent using Alpine/Pine, a text based MUA ---
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[Erik Hanson]

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? (Something authentic) x (Something that
> may or may not be authentic) == (Something that may or may not be
> authentic), right?

It's been mentioned in this thread enough times that MD5 has not fallen
to the attack you think it has, so I won't repeat that talking point,
but I will try and clarify something..

The checksums are not there to verify authenticity. Everyone seems to be
putting far too much stock in the MD5 sums in the .info files. I can't
stress this enough: they're not there for security.

You could almost think of it as a version number. If the file you
download matches the MD5 sum provided, then you know it's the same file
the maintainer used, and the same file the SlackBuild was tested against
by a SlackBuilds.org admin. This helps to ensure the SlackBuild will
work as intended, creating a valid package.

What the MD5 sum can, and does do on a regular basis, is raise a red
flag when it mismatches. Possibly the source has gone missing, or been
replaced by upstream without a change to the file name. These things
happen often enough that it's important we have a checksum, and that
people use it rather than complain that a SlackBuild is broken.

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. Auditing or policing upstream sources is far
beyond the scope of this project. We could use the strongest hashing
algorithm available, but telling people it's a mark of authenticity
would be nothing but theater.


-- 
Erik



signature.asc
Description: OpenPGP digital signature
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[Richard Ellis via SlackBuilds-users]

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 authenticity of the SlackBuild script, 

The .asc files protect the entire slackbuild package.  They verify
that the entire *.tar.gz file has not been modified since the SBo
admins posted the *.tar.gz file to the site.

> but the authenticity of the source tarball itself used by the
> aforementioned script is uncertain?

No.  The MD5 sum being discussed in *inside* the SBo *.tar.gz file in
the *.info file contained therein.  The *.asc file authenticating the
*.tar.gz SBo package allows you (assuming you check the GPG
signature) to determine that the *.tar.gz was not modified, which by
extension means the *.info inside was also not modified since the
package was posted.

Now you know that the *.info was not modified (due to the GPG *.asc
file).  If the *.info file was not modified, then the MD5 sum inside
was also not modified and represents exactly what the maintainer
placed inside the *.info file when they created it.

So with a MD5 sum that you know to have been unmodified (due to
checking the *.asc on the whole bundle) you can verify that the
package source you download from the download link matches the
unmodified MD5 sum in the *.info file.  If they match, you have
verified that the downloaded source package you received is identical
to that which was used by the SBo package maintainer when they
created the SBo *.info file.

The reason this works is that to break this (substitute a different
download package for the origional download package) the attacker has
to perform a second pre-image attack, which remains computationaly
infeasable today even for MD5.

> If that's the case then why would one bother with verifying
> authenticity at all?  (Something authentic) x (Something that may
> or may not be authentic) == (Something that may or may not be
> authentic), right?

The authenticity verification is so you can be sure someone did not
substitute a different copy of myapp.tar.gz from the copy used by the
SBo maintainer when they created the buildscript and *.info file.  An
attacker might try to insert "evil virus" into the download package,
hoping someone would download it in the future and without checking
the hashes compile it up, install it, and now the attacker has a
victim.

___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[Brenton Earl]

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
> > > > verify the .info file contents (and all the rest of the
> > > > SlackBuild
> > > > stuff), not the MD5 sum or whatever else is inside it.
> > > 
> > > 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 situation an opportunity to
> > > MITM
> > > the source tarball itself, since some DOWNLOAD links are
> > > provided 
> > > trough
> > > plain HTTP?
> > 
> > Sources are not protected by us. We do not provide the MD5 sum as
> > any
> > sort of security measure, it shouldn't be treated as one. We have
> > no
> > agency over upstream sources, and we purposefully do not host them,
> > so
> > we cannot provide any signature or sum that could be considered a
> > token
> > of security.
> 
> Thanks for the clarification. I'm still struggling getting the grasp
> of 
> it's effect though..
> 
> Quoting the FAQ from https://slackbuilds.org/faq/#asc
> 
> > 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 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? (Something authentic) x (Something
> that 
> may or may not be authentic) == (Something that may or may not be 
> authentic), right?

The maintainer is supposed to take the GPG signature, MD5 or SHA check
sum from the upstream developer and use it to authenticate the source
prior to uploading a new/updated SlackBuild.  It is the maintainer's
job to verify the source before putting their own check sum into the
.info file.

-- 
Brenton Earl 

signature.asc
Description: This is a digitally signed message part
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[thyr]

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 else is inside it.


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 situation an opportunity to MITM
the source tarball itself, since some DOWNLOAD links are provided 
trough

plain HTTP?


Sources are not protected by us. We do not provide the MD5 sum as any
sort of security measure, it shouldn't be treated as one. We have no
agency over upstream sources, and we purposefully do not host them, so
we cannot provide any signature or sum that could be considered a token
of security.


Thanks for the clarification. I'm still struggling getting the grasp of 
it's effect though..


Quoting the FAQ from https://slackbuilds.org/faq/#asc


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 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? (Something authentic) x (Something that 
may or may not be authentic) == (Something that may or may not be 
authentic), right?

___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[Gabriel Diaz]

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 encryption in the world to protect 
you.

And even though I just mirrored sbosrcarch, I would say slackbuilds should stay 
away from being a third party code distributor.

Anyway I think there is nothing wrong adding SHA1 in the info file, tools can 
ignore or check it as they like. Just don't make it a requirement.

saludos,
gabi






‐‐‐ Original Message ‐‐‐
On August 23, 2018 12:58 PM, Richard Ellis via SlackBuilds-users 
 wrote:

> On Thu, Aug 23, 2018 at 01:45:44AM -0400, T3 slider wrote:
> 

> > On Wed, Aug 22, 2018, 11:15 PM David O'Shaughnessy li...@osh.id.au 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 attack, where the attacker
> > > generates two new archives with new (and matching) MD5s.
> > 

> > 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 around for ages
> > (see https://www.mscs.dal.ca/~selinger/md5collision/ ), so if a
> > SlackBuild includes some documentation as a download link, and the
> > upstream server has since been compromised, a user could definitely
> > be stuck with a malicious file even if the SlackBuild maintainer
> > did everything right and verified upstream signatures.
> 

> The reason the slackbuild MD5's do not fall victim to the "pdf
> collision" attack is a subtle distinction between what crytographers
> define as a "collision" attack vs. a second pre-image attack.
> 

> The pdf attack you describe above is a "collision" attack. A
> collision attack is defined by cryptographers as "find any two files,
> A and B, which produce the same hash" [1]. That was how the PDF
> attack worked, it was just constrained to "the A and B files need to
> be valid PDF files". But, a collision attack does not allow an
> attacker (MITM, etc.) to simply substitute the upstream file with a
> new file that matches the same hash as the origional file.
> 

> In order for an attacker to substitute a different upstream file for
> the origional file, the attacker has to find a new file that matches
> the MD5 hash of the existing file. This attack is what
> cryptographers define as a "second pre-image" attack. And it means
> "given a file G, find another file C which has an identical hash"
> [2]. This is the attack that a MITM ISP or a cracker breaking in to
> an upstream repository has to perform to substitute a different file
> that matches the MD5 in the SBO.
> 

> The reason is that the SBO files contain an MD5 sum of a known file G
> (the origional). And the SBO file is then protected by a GPG
> signature. If a user verifies that the downloaded SBO and GPG
> signature are valid, then the user knows that the SBO has not been
> altered. Therefore the user knows the MD5 sum within the SBO has
> also not been altered (by a MITM or other attack).
> 

> Therefore, in order for the downloaded file (tar ball, zip, pdf,
> whatever) to be altered, but still match the MD5 sum in the SBO, a
> second pre-image attack is requred. This is because the valid MD5
> sum in the SBO is now the sum of a single given file G, and the MITM
> has to find a new file C which hashes to the same MD5 of the given
> file G.
> 

> MD5 has not (yet) been shown to be vulnerable to this attack (second
> pre-image) in any feasable timeframe [3][4]. Yes, a day is going to
> arrive sometime in the future where it will likely fall to a second
> pre-image attack, so upgrading to a stronger hash function is also a
> good idea. But the MD5's are not (yet) a security risk.
> 

> > It is probably more difficult to generate tarballs
> > with collisions but I'm guessing it isn't quite as difficult as we're
> > pretending it is, and it's irrelevant since unzipped files can be passed as
> > download links.
> 

> Cryptographers don't care about what the stream of bytes represent.
> The attack types are defined over the set of "all possible byte
> combinations of inputs to the hash function".
> 

> > Simply put, this is bad security. Anyone who disagrees doesn't understand
> > the problem.
> 

> Well, anyone who confuses collision attacks (which have been shown
> against MD5) with second pre-image attacks (which is what the GPG
> protected MD5 hashes in the SBO force an attacker to achieve) is also
> not fully up to speed on the meaning of the different attacks and the
> security properties they provide and falls int

Re: [Slackbuilds-users] Metacharacters in package names

[Didier Spaier]

On 08/23/2018 12:34 PM, B Watson wrote:
> So, plus, hyphen, and underscore are the only non-alphanumeric characters
> Pat uses. And they're 7-bit ASCII only. Those should be our rules,
> too. I'd even go so far as to say we should stick to that even if Pat
> changes his rules (because Pat doesn't have to care about his package
> names breaking sbopkg, sbotools, etc, and we do, or at least should)
In my opinion tools like sbotool sbopkg and such should be adapted to
handle filenames including other characters than alpha-numeric, plus,
hyphen, and underscore if they appear in Slackware package names.

I don't expect that all 137,374 characters listed in Unicode 11.O will
be used though, anyway less than half of them have an associated
glyph even among the GNU Unifont and Noto fonts ;)

But of course we'd better avoid to use those that can need to be quoted
listed in
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02

Namely:

|  &  ;  <  >  (  )  $  `  \  "  '  

and also:

*   ?   [   #   ˜   =   %

Didier
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[Richard Ellis via SlackBuilds-users]

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 feasible at present.  This is
> > different to a much simpler collision attack, where the attacker
> > generates two _new_ archives with new (and matching) MD5s.
> >
> 
> 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 around for ages
> (see https://www.mscs.dal.ca/~selinger/md5collision/ ), so if a
> SlackBuild includes some documentation as a download link, and the
> upstream server has since been compromised, a user could definitely
> be stuck with a malicious file even if the SlackBuild maintainer
> did everything right and verified upstream signatures.

The reason the slackbuild MD5's do not fall victim to the "pdf
collision" attack is a subtle distinction between what crytographers
define as a "collision" attack vs. a second pre-image attack.

The pdf attack you describe above is a "collision" attack.  A
collision attack is defined by cryptographers as "find any two files,
A and B, which produce the same hash" [1].  That was how the PDF
attack worked, it was just constrained to "the A and B files need to
be valid PDF files".  But, a collision attack does not allow an
attacker (MITM, etc.) to simply substitute the upstream file with a
new file that matches the same hash as the origional file.

In order for an attacker to substitute a different upstream file for
the origional file, the attacker has to find a new file that matches
the MD5 hash of the existing file.  This attack is what
cryptographers define as a "second pre-image" attack.  And it means
"given a file G, find another file C which has an identical hash"
[2].  This is the attack that a MITM ISP or a cracker breaking in to
an upstream repository has to perform to substitute a different file
that matches the MD5 in the SBO.

The reason is that the SBO files contain an MD5 sum of a known file G
(the origional).  And the SBO file is then protected by a GPG
signature.  If a user verifies that the downloaded SBO and GPG
signature are valid, then the user knows that the SBO has not been
altered.  Therefore the user knows the MD5 sum within the SBO has
also not been altered (by a MITM or other attack).

Therefore, in order for the downloaded file (tar ball, zip, pdf,
whatever) to be altered, but still match the MD5 sum in the SBO, a
second pre-image attack is requred.  This is because the valid MD5
sum in the SBO is now the sum of a single given file G, and the MITM
has to find a new file C which hashes to the same MD5 of the given
file G.

MD5 has not (yet) been shown to be vulnerable to this attack (second
pre-image) in any feasable timeframe [3][4].  Yes, a day is going to
arrive sometime in the future where it will likely fall to a second
pre-image attack, so upgrading to a stronger hash function is also a
good idea.  But the MD5's are not (yet) a security risk.

> It is probably more difficult to generate tarballs
> with collisions but I'm guessing it isn't quite as difficult as we're
> pretending it is, and it's irrelevant since unzipped files can be passed as
> download links.

Cryptographers don't care about what the stream of bytes represent. 
The attack types are defined over the set of "all possible byte
combinations of inputs to the hash function".

> Simply put, this is bad security. Anyone who disagrees doesn't understand
> the problem.

Well, anyone who confuses collision attacks (which have been shown
against MD5) with second pre-image attacks (which is what the GPG
protected MD5 hashes in the SBO force an attacker to achieve) is also
not fully up to speed on the meaning of the different attacks and the
security properties they provide and falls into the trap of
"criticis[ing] MD5 and SHA1 for the wrong reasons" [4].

> Can't we just add an optional sha256sum in the .info file and
> maintainers can gradually add these checksums to their SlackBuilds,
> targeting some point in the future that these fields will be required (and
> possibly the md5s retired)?

Upgrading to sha256 is not a bad idea, but the MD5's do not yet
present a "the sky is falling" risk given the way they are verified
via the GPG signature protecting the SBO file.

[1] https://en.wikipedia.org/wiki/Collision_attack
[2] https://en.wikipedia.org/wiki/Preimage_attack
[3] http://www.cs.cmu.edu/~perspectives/md5.html (paragraph beginning
"To understand the implications" up through the paragraph ending
"Perspectives requires only second preimage resistance of MD5")

[4] https://en.wikibooks.org/wiki/Cryptography/Breaking_Hash_Algorithms
  "The MD5 and SHA-1 hash functions, in ap

Re: [Slackbuilds-users] Metacharacters in package names

[B Watson]

On 8/23/18, Didier Spaier  wrote:
>
> Anyway, the '+" character is used in names of packages shipped in Slackware:
> biff+comsat-0.17-x86_64-1
> dvd+rw-tools-7.1-x86_64-2
> gcc-g++-5.5.0-x86_64-1_slack14.2
> gtk+-1.2.10-x86_64-5
> gtk+2-2.24.31-x86_64-1_slack14.2
> gtk+3-3.18.9-x86_64-1
> libcdio-paranoia-10.2+0.93+1-x86_64-1
> libsigc++-2.6.2-x86_64-1

Bingo. Pat never wrote any formal package-naming spec for Slackware,
so all we have to go by is looking at the names he uses and deducing a
set of rules from them.

It means + is allowed... and I wish it weren't, 'cause package names
with + in them have caused problems for my pet project too (sbosrcarch).

It also means it's OK to randomly use names like MPlayer (capital
letters), which drives me insane (because they're effectively random. If
the caps had a meaning, like ClassName and methodName in OO languages,
I'd be less insane...)

How about UTF-8 accented/umlauted characters in package names? Slackware
doesn't ship any packages like that... so we can say "no, not allowed".
If Pat did start shipping a package with an umlaut in the name[*],
would that open the door for all of Unicode? You think + is annoying
to deal with, wait'll you have to handle emoticons, Linear-B, Klingon,
Sanskrit, cuneiform, braille (visually represented) and something like
30,000 Chinese characters...

[*] That's at least theoretically possible: "love" on SBo is actually
called "LÖVE" by its developers (that's an umlauted O, in case gmail
mangles it).

Er, and what point am I making? Not sure. How about this:

$ ls | grep -v SBo | rev | cut -d-
-f4- | rev | sed 's,.,&\n,g' | sort -u | grep -v '[A-Za-z0-9]' | xargs
echo
+ - _

(That's on a full install with nothing but Slackware and SBo packages...)

So, plus, hyphen, and underscore are the only non-alphanumeric characters
Pat uses. And they're 7-bit ASCII only. Those should be our rules,
too. I'd even go so far as to say we should stick to that even if Pat
changes his rules (because Pat doesn't have to care about his package
names breaking sbopkg, sbotools, etc, and we do, or at least should).
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Metacharacters in package names

[Didier Spaier]

On 08/23/2018 08:33 AM, Chris Abela wrote:
> My intention was to solicit your reconsideration on the inclusion of 
> metacharacters in package names. They are a nuisance, ugly and they break 
> things. Which characters are acceptable? Would you also accept white spaces 
> and semi-colons?

Let's distinguish between '+', spaces and semi-colons

'+' is special only in extended regular expression according to POSIX and can 
then be escaped, cf. §9.4.3 ERE Special Characters
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04

The POSIX specification requires that sed supports the basic regular 
expressions but supporting the EREs is not required, cf. Regular Expressions in 
sed:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html#tag_20_116_13_02.

A BRE can always be used instead of an ERE as far as I know.

Anyway, the '+" character is used in names of packages shipped in Slackware:

didier[/var/log/packages]$ ls /var/log/packages|grep '+'
biff+comsat-0.17-x86_64-1
dvd+rw-tools-7.1-x86_64-2
gcc-g++-5.5.0-x86_64-1_slack14.2
gtk+-1.2.10-x86_64-5
gtk+2-2.24.31-x86_64-1_slack14.2
gtk+3-3.18.9-x86_64-1
libcdio-paranoia-10.2+0.93+1-x86_64-1
libsigc++-2.6.2-x86_64-1
didier[/var/log/packages]$

spaces an semi-colons instead shall be quoted if they are to represent 
themselves, cf. the POSIX specification, Shell Command Language  §2.2 Quoting:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02

So in this case not using them in package names is wise.

All this being said I am not a SBo admin, and this is just my opinion.

Didier


 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] MD5 hash sums

[David O'Shaughnessy]

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 around for ages
> (see https://www.mscs.dal.ca/~selinger/md5collision/
>  ), so if a
> SlackBuild includes some documentation as a download link, and the
> upstream server has since been compromised, a user could definitely be
> stuck with a malicious file even if the SlackBuild maintainer did
> everything right and verified upstream signatures. It is probably more
> difficult to generate tarballs with collisions but I'm guessing it isn't
> quite as difficult as we're pretending it is, and it's irrelevant since
> unzipped files can be passed as download links.

I don't see how this works if each individual download (either archive
or single uncompressed file) has its own MD5. My understanding of
collisions is that one can easily create two differing files with
matching MD5 sums (so the original innocuous file A plus a malicious new
file B), but that this necessarily creates a new (shared) MD5 sum. If
the target MD5 is given beforehand (i.e., the one(s) in the info file),
then a preimage attack is required which is impractical.

> 
> Simply put, this is bad security. Anyone who disagrees doesn't
> understand the problem. Can't we just add an optional sha256sum in the
> .info file and maintainers can gradually add these checksums to their
> SlackBuilds, targeting some point in the future that these fields will
> be required (and possibly the md5s retired)?

An optional sha256sum field seems reasonable to me.

--
Dave
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/