Re: [arch-general] Stronger Hashes for PKGBUILDs

[sivmu]

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
>> needs to be clearly advised to use all available methods to effectively
>> verify upstream source files.
>>
>> Using a strong hash by default won't do that.
> 
> AUR packages, or repo packages? There was a todo list[1] for the repos.
> 
> For anything in the AUR you should definitely drop a comment on their
> page. And change the wiki guidelines on packaging standards to mention this.
> 

Wow thanks for the link, I did not kow that yet. That looks awesome.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Installation: How to get HDD > LUKS > GPT working in a clean way

[Merlin Büge]

Hi Paul,


> If another opinion helps, I've done some funky disk layouts at various
> times, and I also think that if you need partitioning above the LUKS layer,
> you'd do better to use LVM than GPT. GPT is intended to be used at the
> lowest level of the stack, whereas LVM is well-supported at pretty much any
> level. If you do go ahead with it, double-check that you won't get block
> alignment issues in that stack that could affect IO performance.

Thanks for your input.
(I already checked alignment of my setup.)


> However, if you say that you don't need the flexibility of LVM, I'd
> certainly first try btrfs directly on top of LUKS.

If I did not want to have a swap partition, I'd to that for sure.
Another possible layout which just comes to mind is

  GPT
  +-LUKS
  | +-Btrfs
  +-LUKS
+-SWAP

I think that should work with hibernation, too, and GPT would be on the right
place + still no LVM :)
Maye I'll just try different layouts over time, haven't experimented much yet.


> Final consideration: if you want GRUB to open a LUKS container and then
> load stage 2 from btrfs, you'll need a decent amount of storage for the
> GRUB 1st stage, which on a traditional setup goes in free space you need
> to account for after the MBR (or on the EFI partition for UEFI setups). In
> your case, as the whole disk is LUKS and you have no partition table, have
> you considered where the GRUB 1st stage will be stored? I use a USB stick
> to boot GRUB stage 1 on my encrypted machines, and that may work for you
> too.

As mentioned in my initial post, I have GRUB2 along with (deblobbed) coreboot
stored in the SPI flash chip (so no BIOS here). It's very convenient :)


Regards,

Merlin



-- 
Merlin Büge 

Re: [arch-general] Stronger Hashes for PKGBUILDs

[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
> needs to be clearly advised to use all available methods to effectively
> verify upstream source files.
> 
> Using a strong hash by default won't do that.

AUR packages, or repo packages? There was a todo list[1] for the repos.

For anything in the AUR you should definitely drop a comment on their
page. And change the wiki guidelines on packaging standards to mention this.

-- 
Eli Schwartz

[1] https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/

Re: [arch-general] Stronger Hashes for PKGBUILDs

[sivmu]

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 MITM attack (which is
>>> trivial if the host uses HTTP) the checksum is still useful.
>>
>> The checksum that was created by zou after downloading the compromised
>> source file.
>>
>> I don't see how that is useful. The checksum will always be correct and
>> validate nothing
>>
> 
> Possibilities
> 
> 1) MITM attack between end-user and internet. PKGBUILD is downloaded
> over HTTPS, but source files are downloaded over HTTP. MITM attack
> cannot manipulate the PKGBUILD, but can fake the sources.
> 
> AUR maintainer was probably not under the same MITM. ;)

Why apply this only to AUR?
The same is true for the regular repositories, but in that case you only
need to MITM the maintainer and the checksums will not help.

But yes for AUR this can help.

> 
> 2) Source website hacked. AUR maintainer blindly generates checksums
> from the compromised source, nothing else matters because everyone is
> screwed.
> 
Except if pgp signatures are provided by upstream und used in the PKGBUILD

> 3) Source website hacked, after the AUR maintainer generates checksums
> from the original uncompromised source.
> 
This use case is valid.


> ...
> 
> In cases #1 & #3 (and #3 is only by accident) stronger checksums *will*
> help.
> Those are also the cases where it is more likely the maintainer is
> security-conscious and checks the sources before generating the
> manually-upgraded-to-sha256-or-higher checksums.
> 
> ...
> 
> Context is everything. I am sure many people who read this thread are
> not aware of the following forum thread in which the matter was
> extensively discussed: https://bbs.archlinux.org/viewtopic.php?id=217588
> 
> 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, people who don't know there
> are defaults to change are probably not your best bet security-wise, and
> the only real security is either PGP or strong checksums posted by
> upstream on a second website.
> Also, that changing the defaults will encourage a false sense of
> security when people think that checksums have any validity in
> authentication.
> 
> Personally, I want the defaults changed because of #1 & #3, but it
> doesn't seem that will happen *as a matter of principle* so I guess
> everyone can continue bikeshedding here. Or in arch-dev-public. (Though
> having a TU take up the fight is indeed somewhat more useful than random
> users, so who knows?)
> 

One valid reason to change the default checksum in general to a stronger
algo, would be to prevent maintainer from using md5 as a security
checksum. It is currently used for error detection during download.

But using a strong hash is only really useful when there is a way to
verify it. e.g. by pgp signatures or at least checksums on a https site.

So if there is a way to verify upstream packages, using md5 inside
PKGBUILD is bad.

If there is no way to verify the upstream packages, using a stronger
hash will provide a false sense of security. And thats what many seem to
use it for. Thats partly why Allan won't change the default (if I
understood him correctly)


I my opinion, the way to solve this is to change the default md5
checksum to a different weaker one, preferably alias it to make sure it
is understood as a error detection algorithmus.
That way maintainers will understand that there is no verification of
upstream packages by default and that they need to take care of that
themselfs.

The second change needed would be to strongly encourage maintainers to
use pgp validation if available or to use strong checksum after getting
packages over https.

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 effectively
verify upstream source files.

Using a strong hash by default won't do that.




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Stronger Hashes for PKGBUILDs

[Maxwell Anselm via arch-general]

>
> 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, people who don't know there
> are defaults to change are probably not your best bet security-wise, and
> the only real security is either PGP or strong checksums posted by
> upstream on a second website.
> Also, that changing the defaults will encourage a false sense of
> security when people think that checksums have any validity in
> authentication.
>

The only change I can think of would be some way for the PKGBUILD to
distinguish between "official" checksums (to defend against all cases) and
"unofficial" checksums (to defend against #1 and #3). But that's a matter
for arch-dev-public.

Re: [arch-general] Stronger Hashes for PKGBUILDs

[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 MITM attack (which is
>> trivial if the host uses HTTP) the checksum is still useful.
> 
> The checksum that was created by zou after downloading the compromised
> source file.
> 
> I don't see how that is useful. The checksum will always be correct and
> validate nothing
> 

Possibilities

1) MITM attack between end-user and internet. PKGBUILD is downloaded
over HTTPS, but source files are downloaded over HTTP. MITM attack
cannot manipulate the PKGBUILD, but can fake the sources.

AUR maintainer was probably not under the same MITM. ;)

2) Source website hacked. AUR maintainer blindly generates checksums
from the compromised source, nothing else matters because everyone is
screwed.

3) Source website hacked, after the AUR maintainer generates checksums
from the original uncompromised source.

...

In cases #1 & #3 (and #3 is only by accident) stronger checksums *will*
help.
Those are also the cases where it is more likely the maintainer is
security-conscious and checks the sources before generating the
manually-upgraded-to-sha256-or-higher checksums.

...

Context is everything. I am sure many people who read this thread are
not aware of the following forum thread in which the matter was
extensively discussed: https://bbs.archlinux.org/viewtopic.php?id=217588

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, people who don't know there
are defaults to change are probably not your best bet security-wise, and
the only real security is either PGP or strong checksums posted by
upstream on a second website.
Also, that changing the defaults will encourage a false sense of
security when people think that checksums have any validity in
authentication.

Personally, I want the defaults changed because of #1 & #3, but it
doesn't seem that will happen *as a matter of principle* so I guess
everyone can continue bikeshedding here. Or in arch-dev-public. (Though
having a TU take up the fight is indeed somewhat more useful than random
users, so who knows?)

-- 
Eli Schwartz

Re: [arch-general] Stronger Hashes for PKGBUILDs

[sivmu]

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 that was created by zou after downloading the compromised
source file.

I don't see how that is useful. The checksum will always be correct and
validate nothing



signature.asc
Description: OpenPGP digital signature

[arch-general] [Classroom] Getting Started with Arch Linux Package Building

[fsckd via arch-general]

New Class, "Getting Started with Arch Linux Package Building"

The class will be held on Sunday, Dec 11th at 19:00 UTC in #archlinux-classroom 
on irc.freenode.net. It is taught by meskarune and halosghost.

This class will give you the understanding and resources to read, edit and 
write your own PKGBUILDs from scratch. The class will be covering basic 
PKGBUILDs as well as version control systems and GPG signed software. You will 
also learn how to check PKGBUILDs for errors and security issues to look out 
for. Everyone is welcome to join. The rules posted in 
https://wiki.archlinux.org/index.php/Code_of_conduct will be enforced.

Prerequisites:
* Have a basic understanding of filesystems and filesystem permissions
* Know basic shell commands
* Know how to extract archives (e.g., `bsdtar -xf filename`)
* Ability to use a text editor (e.g., nano, vim, emacs, etc.)
* Have base and base-devel installed (Arch Linux specific) along with 
pacman/makepkg and namcap

Teachers:

halosghost, resident panda of the Arch Linux community, enjoys programming, 
bagels and banning * on irc.

meskarune is an artist, programmer and sysadmin. She has contributed to FOSS 
for 16 years and been an Arch user for 9 years.

Re: [arch-general] minidlna problems

[Peter Nabbefeld]

Thank You for trying to help me, but it's not been VLC which caused the 
problems. Also, I found some notice about VLC 2.0 not working, seems it 
has been fixed already.


Kind regards
Peter


Am 04.12.2016 um 19:55 schrieb SET:

Le dimanche 4 décembre 2016 17:17:02 CET Mike Cloaked via arch-general a écrit
:

The version current in arch is minidlna 1.1.6-1 but perhaps the comment
earlier in the thread about version 2.x is a heads-up for when the version
in arch is updated in the future at some point to make sure that 2.x does
support UPnP. Certainly minidlna 1.1.6-1 works fine once it is set up
correctly.


The 2.x comment above concerns VLC, and not minidlna. I'm using the same
version as yours, on ALARM too.

Re: [arch-general] minidlna problems

[Peter Nabbefeld]

Thank You - I must admit that my firewall settings have been incorrect, 
though I've been sure I did change them, but obviously I didn't save 
them or sth. else ...


Kind regards
Peter


Am 04.12.2016 um 18:17 schrieb Mike Cloaked via arch-general:

On Sun, Dec 4, 2016 at 4:19 PM, Peter Nabbefeld 
wrote:


Hello Mike,

I cannot find any important differences between Your files and mine. I've
tested VLC, and if this is broken, the test doesn't have any relevance, so
I need some other client first.

Kind regards
Peter



In my case I can run vlc from another machine within my LAN to see the
files on my media server running minidlna - one thing worth checking is
that you don't have any firewall blocks for the required ports on the
server. Again in my case the server is entirely within my home LAN and not
visible to the wider internet, so there are less security concerns in this
case than if the server was being accessed from the WAN.

The version current in arch is minidlna 1.1.6-1 but perhaps the comment
earlier in the thread about version 2.x is a heads-up for when the version
in arch is updated in the future at some point to make sure that 2.x does
support UPnP. Certainly minidlna 1.1.6-1 works fine once it is set up
correctly.

Re: [arch-general] Installation: How to get HDD > LUKS > GPT working in a clean way

[Paul Gideon Dann via arch-general]

On 2 December 2016 at 22:29, Merlin Büge  wrote:

>> Personally, I'd rather modify the start-up process a tiny bit so that
>> GPT inside LUKS gets parsed. I just try to strip off unnecessary
>> 'overhead' / layers of my system.

> If you have 8 GiB or more and not hibernating, don't bother with swap,
> it'd be a waste of disk space. In that case you could just put a btrfs
> volume straight on the LUKS container without the GPT. Problem solved as
> you don't need any more volume management than opening LUKS containers.


If another opinion helps, I've done some funky disk layouts at various
times, and I also think that if you need partitioning above the LUKS layer,
you'd do better to use LVM than GPT. GPT is intended to be used at the
lowest level of the stack, whereas LVM is well-supported at pretty much any
level. If you do go ahead with it, double-check that you won't get block
alignment issues in that stack that could affect IO performance.

However, if you say that you don't need the flexibility of LVM, I'd
certainly first try btrfs directly on top of LUKS.

Final consideration: if you want GRUB to open a LUKS container and then
load stage 2 from btrfs, you'll need a decent amount of storage for the
GRUB 1st stage, which on a traditional setup goes in free space you need
to account for after the MBR (or on the EFI partition for UEFI setups). In
your case, as the whole disk is LUKS and you have no partition table, have
you considered where the GRUB 1st stage will be stored? I use a USB stick
to boot GRUB stage 1 on my encrypted machines, and that may work for you
too.

Paul