Re: [arch-general] arch-general Digest, Vol 141, Issue 16

[Information Technology Works]

On 07/10/2016 10:36 AM, arch-general-requ...@archlinux.org wrote:
> Send arch-general mailing list submissions to
>   arch-general@archlinux.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.archlinux.org/listinfo/arch-general
> or, via email, send a message with subject or body 'help' to
>   arch-general-requ...@archlinux.org
>
> You can reach the person managing the list at
>   arch-general-ow...@archlinux.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of arch-general digest..."
>
>
> Today's Topics:
>
>1. Re: Announcing pacpak (pelzflorian (Florian Pelz))
>2. Re: Announcing pacpak (pelzflorian (Florian Pelz))
>3. Re: Announcing pacpak (Mauro Santos)
>4. Re: Announcing pacpak (Jelle van der Waa)
>5. Re: Announcing pacpak (Levente Polyak)
>6. Re: Announcing pacpak (pelzflorian (Florian Pelz))
>7. Re: Announcing pacpak (pelzflorian (Florian Pelz))
>
>
> --
>
> Message: 1
> Date: Sun, 10 Jul 2016 14:18:00 +0200
> From: "pelzflorian (Florian Pelz)" 
> To: arch-general@archlinux.org
> Subject: Re: [arch-general] Announcing pacpak
> Message-ID: 
> Content-Type: text/plain; charset=utf-8
>
> Hello,
>
> On 07/10/2016 12:52 PM, Bennett Piater wrote:
>> Are you planning to address the catastrophy that ensues when 5000
>> different versions of important libraries are installed at the same
>> time, most of which will always be 5 critical security updates behind?
>>
> The intention is that, once implemented, `pacpak -Syu` or maybe `pacpak
> -Su` will install a current version of all apps and runtimes. Old
> versions of apps and app runtimes that are not used by any app could be
> cleaned by `pacpak -Sc` or a similar command (or automatically?); I?m
> not yet sure what the best interface is.
>
> Note that there is a trade-off between memory consumption and the time
> it takes to update a container. ostree (which is used by Flatpak)
> compresses all runtimes and apps for about half the hard disk memory
> consumption. This greatly increases the time it takes to update a
> container. This may need to be addressed in ostree in the future.
>
>> I am very cynical about this container trend... :/
>>
> The advantage of using pacman for Flatpak is that even pure Flatpak
> users may still be interested in Arch packages, so Arch packages remain
> just as relevant and everything stays mostly the same for those using
> pure pacman.
>
> Regards,
> Florian Pelz
>
>
> --
>
> Message: 2
> Date: Sun, 10 Jul 2016 14:18:24 +0200
> From: "pelzflorian (Florian Pelz)" 
> To: arch-general@archlinux.org
> Subject: Re: [arch-general] Announcing pacpak
> Message-ID: <985a680c-a132-862d-215c-8b8fc601e...@pelzflorian.de>
> Content-Type: text/plain; charset=utf-8
>
> Hello,
>
> On 07/10/2016 01:59 PM, LoneVVolf wrote:
>> My personal preference though is for AL community to treat flatpak
>> similar as derivative distros.
>>
>> something like : flatpak is unsupported on Arch linux, ask the flatpak
>> creator(s) for help.
> Hm? If there is not that much desire to support Flatpak ?officially? as
> an Arch project, then I probably will end up setting up a mailing list
> and bug tracker on my server sometime in the coming weeks.
>
> Regards,
> Florian Pelz
>
>
> --
>
> Message: 3
> Date: Sun, 10 Jul 2016 14:22:07 +0100
> From: Mauro Santos 
> To: arch-general@archlinux.org
> Subject: Re: [arch-general] Announcing pacpak
> Message-ID: <83961152-99e0-b19a-c363-08526ee33...@gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> On 10-07-2016 13:18, pelzflorian (Florian Pelz) wrote:
>> Hello,
>>
>> On 07/10/2016 01:59 PM, LoneVVolf wrote:
>>> My personal preference though is for AL community to treat flatpak
>>> similar as derivative distros.
>>>
>>> something like : flatpak is unsupported on Arch linux, ask the flatpak
>>> creator(s) for help.
>> Hm? If there is not that much desire to support Flatpak ?officially? as
>> an Arch project, then I probably will end up setting up a mailing list
>> and bug tracker on my server sometime in the coming weeks.
>>
>> Regards,
>> Florian Pelz
>>
> Personally I'd rather keep using the good old packages _but_ it would be
> nice to have an official tool to manage/run/create flatpak packages,
> this just to make sure that in case one needs to use a flatpak package
> nothing will screw up the filesystem and cause more trouble than it's worth.
>
> However a big fat warning should be present somewhere that bugs/problems
> with flatpak packages are the sole responsibility of upstream/the
> creator as I suspect bugs and problems will be the norm.
>
Aren't  snaps, flatpak and appimage missing the boat in a concerning
way? Shouldn't the 

Re: [arch-general] arch-general Digest, Vol 140, Issue 10

[Information Technology Works]

On 06/08/2016 08:00 PM, arch-general-requ...@archlinux.org wrote:
> been using thunderbird which
> automatically does that for mail lists - now with it's impending demise
> I am trying other mailers
https://blog.mozilla.org/thunderbird/files/2016/04/Finding-a-Home-for-Thunderbird.pdf

Re: [arch-general] arch-general Digest, Vol 139, Issue 15

[Information Technology Works]

On 05/17/2016 11:16 AM, arch-general-requ...@archlinux.org wrote:
> I started some preliminary work with Levente, and first indications are that 
> we should see very little in terms of performance impact. I have begun work 
> on an automated testing framework, which will be located here: 
> https://github.com/pid1/test-sec-flags
>
> Ideally, we will automatically use various combinations of flags, and log the 
> benchmarks of each for later comparison.
>
> Patches welcome.
>
> Cheers,
> pid1
great! I'll have my ears on. full aslr would be a big deal for arch and
it's users.

thanks,
ITwrx

Re: [arch-general] arch-general Digest, Vol 139, Issue 14

[Information Technology Works]

On 05/17/2016 07:00 AM, arch-general-requ...@archlinux.org wrote:
> In the past there has been various (performance) reasons with gcc5 that
> hold up stepping further, so the decision was to not backport gcc6
> patches and wait for gcc6 so arrive. Fortunately gcc6 arrived so the
> topic landed again on the tables for discussion. The current state is
> that we wanted to have some benchmarking with current (non-PIE) and PIE
> enabled binaries to compare them and make sure it eliminated all
> previous concerns.
>
> If you want to to really help pushing this topic in an official way then
> the most useful and best step you could do is helping out to do those
> benchmarks.
>
> cheers,
> Levente
ohh, ok. that makes sense. I would be glad to benchmark as many packages
as needed, assuming someone doesn't mind telling me how it needs to be
done. 

thanks,

ITwrx

[arch-general] PIE repo considerations

[Information Technology Works]

i was wondering if anyone had any ideas on how one might setup
unofficial user repos with all the offical arch packages but built with
hardening-wrapper.

presumed needs
1) download latest sources for all official arch packages. abs does this
but i's rather not wait up to a day to get security updates. Why doesn't
abs just sync however the repo mirrors do?

2) build all of them (with hardening-wrapper) automatically

3) auto-rebuild when arch official package gets upgraded.

4) make available as binary packages in unofficial user repo.(assuming
arch doesn't want to have official aslr repos)

For #1 i'm thinking asp would be nice as it grabs the latest
sources but it doesn't currently have an "-all" option or similar.
Assuming its dev would add it, do scripts or packages currently exist
that would facilitate the other items(mainly 2 & 3 above)?

-

https://www.archlinux.org/packages/community/x86_64/hardening-wrapper/

https://wiki.archlinux.org/index.php/DeveloperWiki:Security#PIE

>From what i glean from the conversation below, i think a (totally
theoretical) user vote would have resulted in an affirmative on full aslr:

https://lists.archlinux.org/pipermail/arch-dev-public/2014-December/026843.html

I also don't understand the lack of discussion on something this
important by other devs. one person had concerns about various things
and another mentioned whether upstream would support it and that was it.
I was hoping to at least hear why the wrapper method was so out of spec
for arch as to warrant not supporting full aslr. I'm sure it seems
obvious to those devs opposed, but not to me or possibly other end
users. Also, i don't think i'm owed an explanation. I'm just saying more
context for something this important would have been nice.

thanks,
ITwrx