On Mon, May 14, 2018 at 11:01:57AM -0400, Eli Schwartz via arch-general wrote:
> We're currently in feature freeze for pacman 5.1
>
> Anyone who hopes to have b2sum support in *future* versions of pacman,
> would be well advised to come across as a person seeking to extend
> support for the curren
On 05/14/2018 10:48 AM, Leonid Isaev via arch-general wrote:
> On Mon, May 14, 2018 at 11:23:39AM +0100, Ralph Corderoy wrote:
>> Hi Eli,
>>
>>> Maybe you could ask the coreutils developers whatever happened to
>>> implementing Keccak checksumming tools.
>>
>> SHA-3? Have you see
>> https://www.im
On Mon, May 14, 2018 at 11:23:39AM +0100, Ralph Corderoy wrote:
> Hi Eli,
>
> > Maybe you could ask the coreutils developers whatever happened to
> > implementing Keccak checksumming tools.
>
> SHA-3? Have you see
> https://www.imperialviolet.org/2017/05/31/skipsha3.html
> I've also seen suggest
Hi Eli,
> Maybe you could ask the coreutils developers whatever happened to
> implementing Keccak checksumming tools.
SHA-3? Have you see
https://www.imperialviolet.org/2017/05/31/skipsha3.html
I've also seen suggestions that the Keccak team push Kangaroo Twelve
these days over SHA-3 due to SHA-
On 05/13/2018 08:11 PM, Leonid Isaev via arch-general wrote:
> On Sun, May 13, 2018 at 08:19:19PM +0200, Neven Sajko via arch-general wrote:
>> On 13 May 2018 at 20:11, Neven Sajko wrote:
>>> I do agree that using md5 is absurd, ...
>>
>> To clarify, md5 *is* unsecure and is even slower or not sig
On Sun, May 13, 2018 at 08:19:19PM +0200, Neven Sajko via arch-general wrote:
> On 13 May 2018 at 20:11, Neven Sajko wrote:
> > I do agree that using md5 is absurd, ...
>
> To clarify, md5 *is* unsecure and is even slower or not significantly
> faster than hashes from the Keccak and BLAKE2 famili
On 13 May 2018 at 20:11, Neven Sajko wrote:
> I do agree that using md5 is absurd, ...
To clarify, md5 *is* unsecure and is even slower or not significantly
faster than hashes from the Keccak and BLAKE2 families; using
signatures would be a plus but signatures are not an argument for md5.
I do agree that using md5 is absurd, but putting effort into using
sha-2 seems like a waste when Keccak and BLAKE2 are both faster and
more secure than the old hashes.
Regards,
Neven
The single most beneficial change would be adoption of
The Update Framework, since it is resilient against
all known issues with remote package management,
regardless of pkg signers coming/going and whether
HTTPS is used or not. It also has a nice protocol
for handling key revocation.
On 05/10/2018 05:46 AM, Leonid Isaev via arch-general wrote:
> In this regard, I don't understand why we need checksums at all? If upstream:
> (1) signes source with GPG, it will take care of both integrity and
> authenticity, so no need for hashes;
> (2) doesn't provide signatures, rely on gz
On Thu, 10 May 2018 03:46:34 -0600, Leonid Isaev via arch-general wrote:
>GPG is not complicated at all.
https://aur.archlinux.org/pkgbase/linux-rt/#comment-645504
SICR
--
pacman -Q linux{,-rt{,-pussytoes,-securityink,-cornflower}}|cut -d\ -f2
4.16.7-1
4.16.7_rt1-1
4.14.34_rt27-1
4.14.29_rt25-
On Thu, May 10, 2018 at 10:06:08AM +0200, NicoHood wrote:
> I really like you effort on stronger hashes. I totally aggree with you
> that we need those, if we can't have GPG signatures by the maintainers.
> Hashes just help in less usecases than GPG signatures, of course, but
> they do.
Currently,
On 05/10/2018 01:25 AM, Leonid Isaev via arch-general wrote:
> On Wed, May 09, 2018 at 09:30:51PM +0200, Neven Sajko wrote:
>> I would just like to note that SHA-2 hashes are inferior to Keccak and
>> to BLAKE2. So better not to spend effort migrating to SHA-2.
>
> Strength of various SHA hashes i
Op do 10 mei 2018 01:26 schreef Leonid Isaev via arch-general <
arch-general@archlinux.org>:
> On Wed, May 09, 2018 at 09:30:51PM +0200, Neven Sajko wrote:
> > I would just like to note that SHA-2 hashes are inferior to Keccak and
> > to BLAKE2. So better not to spend effort migrating to SHA-2.
>
On Wed, May 09, 2018 at 09:30:51PM +0200, Neven Sajko wrote:
> I would just like to note that SHA-2 hashes are inferior to Keccak and
> to BLAKE2. So better not to spend effort migrating to SHA-2.
Strength of various SHA hashes is a different topic. My only point was that
relying on md5 these days
On 05/08/2018 10:38 PM, Eli Schwartz via arch-general wrote:
> This is honestly a much better use of everyone's time.
It is indeed a rare occurrence to see the uncommon common sense rear its
lonely head from time to time... but comforting.
--
David C. Rankin, J.D.,P.E.
signature.asc
Descripti
I would just like to note that SHA-2 hashes are inferior to Keccak and
to BLAKE2. So better not to spend effort migrating to SHA-2.
On Wed, May 09, 2018 at 12:31:39AM -0400, Eli Schwartz via arch-general wrote:
> PGP keys are also far more likely to appear in multiple independently
> verifiable locations, you can embed them in your DNS records, post them
> on your blog, github profile, keybase.io proofs utilizing DNS as well as
On 05/08/2018 11:53 PM, Leonid Isaev via arch-general wrote:
>> - not any sort of security check at all, they're there for CRC purposes,
>> and using strong CRC is security theater because the maintainer
>> probably just blindly ran updpkgsums without checking anything at all
>> so they gener
On Tue, May 08, 2018 at 11:38:01PM -0400, Eli Schwartz via arch-general wrote:
> When you say "still", that implies that there was any sort of effort to
> change that in the first place...
Fair enough :) I thought it's a slow natural process...
> - not any sort of security check at all, they're t
On 05/08/2018 10:08 PM, Leonid Isaev via arch-general wrote:
> Hi,
>
> I'm intentionally using the title from Nov/Dec 2016 [0] to ease
> googling. I decided to check the status of this, and there is still 325
> packages with only md5sums in [core] and [extra] (I didn't check [community]).
>
On Tue, May 08, 2018 at 08:08:31PM -0600, Leonid Isaev wrote:
> [extra]
> ...
This list should also include "python-retrying". I should have grepped more
carefully, sigh...
--
Leonid Isaev
On Tue, May 08, 2018 at 08:08:31PM -0600, Leonid Isaev wrote:
> [0] https://lists.archlinux.org/pipermail/arch-general/2016-December/042
Oops, this link should have been
https://lists.archlinux.org/pipermail/arch-general/2016-December/042700.html
--
Leonid Isaev
Hi,
I'm intentionally using the title from Nov/Dec 2016 [0] to ease
googling. I decided to check the status of this, and there is still 325
packages with only md5sums in [core] and [extra] (I didn't check [community]).
Below results are generated by the attached script... Is there anything
On Tue, Dec 27, 2016 at 6:09 PM, Leonid Isaev <
leonid.is...@jila.colorado.edu> wrote:
> On Mon, Dec 26, 2016 at 01:35:23PM +0100, NicoHood wrote:
> > ArchLinux wants to KISS, so we should simply add stronger hashes instead
> > of requiring the user to download two tools. Its quite a struggle to
>
On 12/26/2016 07:35 AM, NicoHood wrote:
>>> Yesterday I wanted to install ArchLinux on someone else computer. He
>>> used Windows until now and had no gpg handy yet (it is really annoying
>>> to install on windows).
What is wrong with, say, Gpg4win?
Okay, it is difficult to *trust* the software w
On Mon, Dec 26, 2016 at 01:35:23PM +0100, NicoHood wrote:
> ArchLinux wants to KISS, so we should simply add stronger hashes instead
> of requiring the user to download two tools. Its quite a struggle to
> find a hash tool for windows anyways.
How about Microsoft FCIV [1]?
[1] https://www.micros
On 26.12.2016 13:12, NicoHood wrote:
> So we needed to verify the source otherwise. But there was no real
> option as md5/sha1 is broken
I fully agree that using stronger hashes is generally a good idea, but
please stop being ridiculous.
> and his internet is too slow to download it
> again via t
On 12/26/2016 01:21 PM, Allan McRae wrote:
> On 26/12/16 22:12, NicoHood wrote:
>>
>>
>> On 12/16/2016 05:46 PM, Diego Viola via arch-general wrote:
>>> On Sat, Dec 3, 2016 at 3:27 AM, fnodeuser wrote:
https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.html
On 26/12/16 22:12, NicoHood wrote:
>
>
> On 12/16/2016 05:46 PM, Diego Viola via arch-general wrote:
>> On Sat, Dec 3, 2016 at 3:27 AM, fnodeuser wrote:
>>> https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.html
>>>
>>> i have a few things to add to this.
>>>
>>> the mes
On 12/16/2016 05:46 PM, Diego Viola via arch-general wrote:
> On Sat, Dec 3, 2016 at 3:27 AM, fnodeuser wrote:
>> https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.html
>>
>> i have a few things to add to this.
>>
>> the message digests at the download page for the .iso
On Sat, Dec 3, 2016 at 3:27 AM, fnodeuser wrote:
> https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.html
>
> i have a few things to add to this.
>
> the message digests at the download page for the .iso file, must change to
> sha256 and sha512 ones, or to a sha512 one.
>
On 16/12/16 21:28, NicoHood wrote:
> make sha512 the default
Hey... guess what is still not happening?
On 12/16/2016 09:59 AM, Levente Polyak wrote:
> On 12/16/2016 06:03 AM, Eli Schwartz via arch-general wrote:
>> On 12/15/2016 08:35 PM, fnodeuser wrote:
>>> what i said is that the users must check the integrity of the sources too.
>>> it is not something that only the package maintainers must do.
On 16/12/16 11:35, fnodeuser wrote:
> "With great power comes great responsibility."
> -Uncle Ben
I will not have misquotes on this mailing list!
On 12/16/2016 06:03 AM, Eli Schwartz via arch-general wrote:
> On 12/15/2016 08:35 PM, fnodeuser wrote:
>> what i said is that the users must check the integrity of the sources too.
>> it is not something that only the package maintainers must do.
>> the users must check the PKGBUILD files to compa
On 12/15/2016 08:35 PM, fnodeuser wrote:
> hello eli,
>
> you have misread and misunderstood a few things.
No I haven't. But you've broken the response headers again in your
reply. Using temporary email addresses on the mailing list is incredibly
annoying; if you are that concerned about your pri
hello eli,
you have misread and misunderstood a few things.
reread carefully all the messages about the subject,
and check the links in my second email.
i will write only about things that are not covered by the
previous messages.
>Sure they're the same. It is the same underlying technology
yo
Le 10/12/2016 à 00:30, Leonid Isaev a écrit :
> On Fri, Dec 09, 2016 at 03:15:34PM +0100, Bruno Pagani wrote:
>> Le 08/12/2016 à 01:57, Leonid Isaev a écrit :
>>
>>> On Thu, Dec 08, 2016 at 10:34:59AM +1000, Allan McRae wrote:
On 08/12/16 08:51, sivmu wrote:
> Am 07.12.2016 um 10:49 schri
On Fri, Dec 09, 2016 at 03:15:34PM +0100, Bruno Pagani wrote:
> Le 08/12/2016 à 01:57, Leonid Isaev a écrit :
>
> > On Thu, Dec 08, 2016 at 10:34:59AM +1000, Allan McRae wrote:
> >> On 08/12/16 08:51, sivmu wrote:
> >>> Am 07.12.2016 um 10:49 schrieb Allan McRae:
> > ...
> > I advocate kee
On 10/12/16 02:05, NicoHood wrote:
> An official rule would be still better. So let us know what you (devs)
> think about this finally.
Been there, done that...
On 12/08/2016 03:14 PM, Bennett Piater wrote:
>>> Is there any voting system that we have so that we can also
>>> democratically vote for stronger hashes?
>>
>> The Arch developers decide this, not a democratically vote ;).
>
> Arch is not a democracy, that has been said many times.
>
That is tr
Le 08/12/2016 à 01:57, Leonid Isaev a écrit :
> On Thu, Dec 08, 2016 at 10:34:59AM +1000, Allan McRae wrote:
>> On 08/12/16 08:51, sivmu wrote:
>>> Am 07.12.2016 um 10:49 schrieb Allan McRae:
> ...
> I advocate keeping md5sum as the default because it is broken. If I see
> someone pur
Okay, first things first -- what happened to replying in-thread with a
message-id linking together replies?
Oh right, you are once again using disposable, temporary Mailinator
email addresses (via their alternate domains).
Admin note: Please, someone add everything here to the invalid email
domai
checksums and message digests are not the same thing.[1]
checksums are not suitable for integrity verification, and the best (meaning,
at the time of writing and for the foreseeable future, most secure),
currently supported cryptographic hash function algorithm (that is sha512 in
AL's case), mus
>> Is there any voting system that we have so that we can also
>> democratically vote for stronger hashes?
>
> The Arch developers decide this, not a democratically vote ;).
Arch is not a democracy, that has been said many times.
--
GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96
On Thu, 8 Dec 2016 14:52:20 +0100, NicoHood wrote:
>Is there any voting system that we have so that we can also
>democratically vote for stronger hashes?
The Arch developers decide this, not a democratically vote ;).
On 12/08/2016 01:34 AM, Allan McRae wrote:
> On 08/12/16 08:51, sivmu wrote:
>> Am 07.12.2016 um 10:49 schrieb Allan McRae:
...
I advocate keeping md5sum as the default because it is broken. If I see
someone purely verifying their sources using md5sum in a PKGBUILD (and
not pgp
On Thu, Dec 08, 2016 at 10:34:59AM +1000, Allan McRae wrote:
> On 08/12/16 08:51, sivmu wrote:
> > Am 07.12.2016 um 10:49 schrieb Allan McRae:
> >> > ...
> >> > I advocate keeping md5sum as the default because it is broken. If I see
> >> > someone purely verifying their sources using md5sum in a P
On 08/12/16 08:51, sivmu wrote:
> Am 07.12.2016 um 10:49 schrieb Allan McRae:
>> > ...
>> > I advocate keeping md5sum as the default because it is broken. If I see
>> > someone purely verifying their sources using md5sum in a PKGBUILD (and
>> > not pgp signature), I know that they have done nothin
On Wed, 7 Dec 2016 11:44:11 +0100
Bennett Piater wrote:
> Maybe giving a warning ("source authenticity was not verified due to
> lack of GPG signature") would work?
I find this a great idea.
It's transparent, and this way people get frequently reminded about that
security issue.
Or like sivmu s
Am 07.12.2016 um 10:49 schrieb Allan McRae:
> ...
> I advocate keeping md5sum as the default because it is broken. If I see
> someone purely verifying their sources using md5sum in a PKGBUILD (and
> not pgp signature), I know that they have done nothing to actually
> verify the source themselves.
On Wed, Dec 07, 2016 at 01:58:16AM -0800, Gregory Mullen wrote:
> > I advocate keeping md5sum as the default because it is broken. If I see
> someone purely verifying their sources using md5sum in a PKGBUILD (and
> not pgp signature), I know that they have done nothing to actually
> verify the sou
> You are partly right. For a checksum CRC would be best. Fast and
> simple, as its meant as checksum, not as a hash.
You misunderstand something. Every checksum is also a hash (a mapping to
another domain), and cryptographic hash functions always produce checksums.
> So possibly we should get o
On 12/07/2016 10:49 AM, Allan McRae wrote:
>
> I advocate keeping md5sum as the default because it is broken. If I see
> someone purely verifying their sources using md5sum in a PKGBUILD (and
> not pgp signature), I know that they have done nothing to actually
> verify the source themselves.
>
> I
On 07-12-16 11:44, Bennett Piater wrote:
On 12/07/2016 11:17 AM, Gregory Mullen wrote:
If the argument left is, I don't want (better checksum) because it's
shouldn't be thought of as a security check, and I want a security check.
Why can't the requirement be PGP sig's are now required, and we d
On 12/07/2016 11:17 AM, Gregory Mullen wrote:
> If the argument left is, I don't want (better checksum) because it's
> shouldn't be thought of as a security check, and I want a security check.
>
> Why can't the requirement be PGP sig's are now required, and we drop the
> checksum completely?
Won'
Off-topic for amusement only:
PGP checks are not necessarily more secure.
Some foolish comments are already deleted at
https://aur.archlinux.org/packages/freetype2-infinality/?comments=all
Somebody recommended to e.g. use "--skippgpcheck", another reply asked
from where I got the information wha
If the argument left is, I don't want (better checksum) because it's
shouldn't be thought of as a security check, and I want a security check.
Why can't the requirement be PGP sig's are now required, and we drop the
checksum completely?
On Wed, Dec 7, 2016 at 2:14 AM, Bennett Piater wrote:
> >
> In fact, I am making CRC the default.
I assume this to be sarcasm.
In any case, this may not be a good idea because the younglings will
have never heard about it and don't know how insecure it is ;)
Cheers,
Bennett
--
GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
signa
On 07/12/16 19:58, Gregory Mullen wrote:
>> But we don't care about that... we just want to feel warm and fuzzy with
> a false sense of security.
>
> No one is suggesting sha*sum replace, and actual security/authentication
> check. Only that maybe it's not a good idea to use a system we all know
> I advocate keeping md5sum as the default because it is broken. If I see
someone purely verifying their sources using md5sum in a PKGBUILD (and
not pgp signature), I know that they have done nothing to actually
verify the source themselves.
I advocate making the default house construction straw.
On 07/12/16 19:35, Gregory Mullen wrote:
> Grayhatter here, developer of Tox -- The security centered TAV client. No
> matter what the reason is, NO ONE should be using MD5. We can argue about
> what hash we want to use, but literally nothing, is better than using MD5.
> I don't mean MD5 is better
Grayhatter here, developer of Tox -- The security centered TAV client. No
matter what the reason is, NO ONE should be using MD5. We can argue about
what hash we want to use, but literally nothing, is better than using MD5.
I don't mean MD5 is better than everything else, I mean NOT using a hash,
is
On 12/03/2016 10:37 PM, Maxwell Anselm via arch-general wrote:
>> You mean the source files that you downloaded and then hashed...
>>
> Yes. If the source files are being modified via a MITM attack (which is
> trivial if the host uses HTTP) the checksum is still useful.
This sounds a lot like a "s
On 12/05/2016 11:45 PM, Eli Schwartz via arch-general wrote:
> On 12/05/2016 05:25 PM, sivmu wrote:
>> A LOT of packages do not use pgp validation even though upstream
>> provides signatures. That is the real issue here.
>>
>> Let me say this again: everyone who is responsible for arch packages
>
Am 05.12.2016 um 23:45 schrieb Eli Schwartz via arch-general:
> On 12/05/2016 05:25 PM, sivmu wrote:
>> A LOT of packages do not use pgp validation even though upstream
>> provides signatures. That is the real issue here.
>>
>> Let me say this again: everyone who is responsible for arch packages
On 12/05/2016 05:25 PM, sivmu wrote:
> A LOT of packages do not use pgp validation even though upstream
> provides signatures. That is the real issue here.
>
> Let me say this again: everyone who is responsible for arch packages
> needs to be clearly advised to use all available methods to effecti
Am 05.12.2016 um 21:50 schrieb Eli Schwartz via arch-general:
> On 12/05/2016 02:56 PM, sivmu wrote:
>> Am 04.12.2016 um 05:37 schrieb Maxwell Anselm via arch-general:
You mean the source files that you downloaded and then hashed...
>>>
>>> Yes. If the source files are being modified via a M
>
> Allan has already declared that he will not change the default
> makepkg.conf, on the grounds that #2 is the most likely scenario for
> people getting malicious packages.
> He also wants everyone to know that updpkgsums and makepkg are perfectly
> okay with maintainers changing the defaults, pe
On 12/05/2016 02:56 PM, sivmu wrote:
> Am 04.12.2016 um 05:37 schrieb Maxwell Anselm via arch-general:
>>> You mean the source files that you downloaded and then hashed...
>>
>> Yes. If the source files are being modified via a MITM attack (which is
>> trivial if the host uses HTTP) the checksum is
Am 04.12.2016 um 05:37 schrieb Maxwell Anselm via arch-general:
>>
>> You mean the source files that you downloaded and then hashed...
>>
>
> Yes. If the source files are being modified via a MITM attack (which is
> trivial if the host uses HTTP) the checksum is still useful.
>
The checksum th
>
> So what do you guys think if we make our implicit standards available
> somewhere on the wiki. This would make it more transparent on how we
> build stuff, how TUs should package and give a guideline for AUR
> maintainers, as they might not know about some details like this.
>
The best way to
On 12/03/2016 07:21 PM, sivmu wrote:
>
>
> Am 03.12.2016 um 06:27 schrieb fnodeuser:
>
>>
>> if an upstream does not sign the files, does not have https enabled, and/or
>> refuses to take security and privacy seriously, sha512 must be used in the
>> PKGBUILD files.
>
> But using and hash va
>
> You mean the source files that you downloaded and then hashed...
>
Yes. If the source files are being modified via a MITM attack (which is
trivial if the host uses HTTP) the checksum is still useful.
On Sat, Dec 3, 2016 at 6:27 AM, fnodeuser wrote:
> https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.html
I would suggest considering TUF - The Update Framework or stealing their
signing scheme which withstands all kinds of attack scenarios.
Am 03.12.2016 um 20:07 schrieb Maxwell Anselm via arch-general:
>>
>> I agree that we should use a strong hash by default where it makes
>> sense. But in the absense ob effective validation of upstream packages,
>> this is meaningless.
>>
>
> It would at least indicate that the source file has b
>
> I agree that we should use a strong hash by default where it makes
> sense. But in the absense ob effective validation of upstream packages,
> this is meaningless.
>
It would at least indicate that the source file has been tampered with in
some way. Even though there would be no way to know th
Am 03.12.2016 um 06:27 schrieb fnodeuser:
>
> if an upstream does not sign the files, does not have https enabled, and/or
> refuses to take security and privacy seriously, sha512 must be used in the
> PKGBUILD files.
But using and hash value without the possibility to verify the hashed
files
> if an upstream does not sign the files, does not have https enabled, and/or
> refuses to take security and privacy seriously, sha512 must be used in the
> PKGBUILD files.
Then
1) you could argue our using SHA512 is meaningless, but
2) it doesn't matter; we should still be doing the Right™
https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.html
i have a few things to add to this.
the message digests at the download page for the .iso file, must change to
sha256 and sha512 ones, or to a sha512 one.
if an upstream does not sign the files, does not have https
81 matches
Mail list logo
