- Arch-general - lists.archlinux.org

[arch-general] [Q] What is sign-off?
by Dragon ryu 30 Apr '17

30 Apr '17

I wonder what is meaning. Also exsample will be appreciated

2 3

[arch-general] [Questions] Questions from past project and ideas fomr -dev-public that get silence.
by Pablo Roberto Lezaeta Reyes 30 Apr '17

30 Apr '17

During this and the end of previous year some ideas and projects were started to adress some problems, but most of them get now silence and nothing more. I'm talking about * ABS deprecation draft, Will be one or just ABS will be removed and ASP (which sound like Active Server Pages) will be pushed or both will coexist until it get broken? * What happend with the project of sign-off from non TU that was mentioned a few months? Is still runing? is there a way/path to get involved? * What about the new build flags [1], Now that Allan is not more the maintainer and that either Debian and Fedora enabled PIE on binutils sucessfully aparently, What will happend? Will it be enabled? What about the other flags? [1] https://www.archlinux.org/news/test-sec-flags-call-for-assistance/ -- *Pablo Lezaeta*

2 1

[arch-general] Tobias Powalowski and his nonsensical maintenance decisions
by fnodeuser 30 Apr '17

30 Apr '17

Tobias Powalowski, you continue to place pkgs in the testing repo that do not require any further testing. for what reasons, exactly, do the linux 4.10.13 and hwids 20170328 pkgs need to be in testing for 4+ days? also, you did not replace git:// with git+https:// in the hwids PKGBUILD file. github has HTTPS enabled for everything.

9 14

Re: [arch-general] Tobias Powalowski and his nonsensical maintenance decisions
by Dragon ryu 29 Apr '17

29 Apr '17

2017/04/30 午前5:58 "fnodeuser" <fnodeuser(a)binkmail.com>: i do not thank you for your conclusion jumping and for the censorship ("I have put you on moderation."). you have disappointed me Florian. time to set the record straight. > Florian Pritz, > > 1. i am not annoying, i am rational. > > 2. testing the stable minor releases makes no sense. we should be testing the release candidates of 4.11 > since its stable release is nearing. that would actually be beneficial to the users. the placing of stable > minor releases in testing is only delaying the distribution of the fixes to the users. > > also, AL users are expected to RTFM. AL is for advanced users and for people who are willing to learn how to > administrate their system(s). > > 3. he has known about it for many months. https://www.archlinux.org/ todo/use-gpg-signatures-and-https-sources/ the above reply was rejected yesterday by little Florian for this reason: > The moderator gave the following reason for rejecting your request: > > "Your message was deemed inappropriate by the moderator." i know. it is so 'inappropriate' that Pope Francis would have died if he ever read it. now, on to the rest. about the '4+ days' thing. reread my message, carefully, because you have difficulties comprehending what i typed. hint: it is about delaying things for no good reason. two more maintenance examples, a recent Antonio Rojas one (once again, he edited today another imperfect PKGBUILD file and left it imperfect), and a Sébastien Luttringer one (an example of stupidity): https://git.archlinux.org/svntogit/packages.git/commit/ trunk/PKGBUILD?h=packages/help2man&id=47e0c555b37f059be552a930a5da80 130942d5a6 an md5 hash is still used and ftp.gnu.org is HTTPS-enabled. nevertheless, i must say that he has improved. https://git.archlinux.org/svntogit/packages.git/commit/ trunk/PKGBUILD?h=packages/btrfs-progs&id=c2dab0f16df636bb0ea94e54d7f116 d5d1504e60 https://www.kernel.org/pub/linux/kernel/people/kdave/ btrfs-progs/sha256sums.asc he has learning difficulties. Carsten Mattner, yes, it is true. sometimes things break, but things can be fixed and there are ways to avoid breakage. RTFM and/or RTFW is a requirement.[1] also, because of evolution, each one of us possess a brain that can do 'miracles' when it is actually used. use it, people. i know that there are people for whom the activity of thinking is extremely painful, but we cannot stop 'rolling' because of them. in almost all cases it is the AL user's fault. if one is careless and clueless, bad things can and do happen. that is true almost everywhere, not only in system administration. - "They see me rollin', They hatin'!" (AL is a rolling release distro, and we want to (rock and) 'roll' forever) _ [1] https://wiki.archlinux.org/index.php/Pacman#Skip_package_ from_being_upgraded https://wiki.archlinux.org/index.php/Pacman#Skip_package_ group_from_being_upgraded https://wiki.archlinux.org/index.php/Pacman#Skip_files_ from_being_installed_to_system PS: Florian's censorship necessitated the use of a different address. any complaints about the message being out of the existing threads are invalid and remarks about my disposable email address are irrelevant. Florian, remove me immediately from 'moderation' to prove: 1. that you actually want to have an honest discussion about anything and everything, 2. that you are a decent person. PPS: whoever you are, you are so cute! port scanning my IP address yesterday, and today registering around with my name. Whoa. Why PKGBUILD need to be perfect? don't need to... And I think PKGBUILD is only thing in AUR, not in this Mailing list. Also, you need to calm down a little bit, think about what you did. - Chroma/Proj. Chisaki

1 0

Re: [arch-general] End of official PaX and grsecurity support in Arch Linux
by Alexander Harrigan 29 Apr '17

29 Apr '17

Name doesn't matter. When it breaks with systemd then it will be stopped but that won't be in months. Paxd is avalaible and it always be assumed to maintain it by yourself. Also I see contradiction when you say many critical grsecurity features won't be avalaible in mainline kernels anytime soon and same time you say there is no sense to use last grsec kernel as long as we can. I'm not asking you to maintain it. There is a chance that gentoo|opensuse|debian guys step in to do it. In that case it will be beneficial to Arch having it avalaible in AUR. Anyway I'll be using grsec kernel myself until something like linux-hardened be avalaible. On On Sat, Apr 29, 2017 at 07:20 PM, Daniel Micay via arch-general <arch- general(a)archlinux.org> wrote: > On Sat, 2017-04-29 at 17:03 +0000, Alexander Harrigan wrote: > > I found someone from opensuse started to maintain grsec patches for > > 4.9 kernel > > series [1]. Maybe it will be possible to add linux-lts-grsec package > > to AUR > > based on Daniel's PKGBUILD and config with RANDSTRUCT enabled linked > > to new > > upstream source. > > > > [1] https://github.com/kdave/grsecurity-patches/tree/master/wip > > As I mentioned, it can't be called PaX or grsecurity. I also don't think > it makes sense to expend time on this. It won't support new hardware and > systemd will probably increase the minimum kernel version before the 4.9 > LTS is end-of-life. Effort spent on 4.9 is effort not spent on anything > that will actually last. If someone decides to do this, they'll also be > taking responsibility for maintaining PaX exceptions, etc. and handling > any bugs caught by the features or false positives. There will be new > issues introduced as the LTS gets changes backported to it. \-- Sent using MsgSafe.io's Free Plan Private, encrypted, online communication For everyone. https://www.msgsafe.io

2 1

[arch-general] Tobias Powalowski and his nonsensical maintenance decisions
by fnodeuser 29 Apr '17

29 Apr '17

i do not thank you for your conclusion jumping and for the censorship ("I have put you on moderation."). you have disappointed me Florian. time to set the record straight. > Florian Pritz, > > 1. i am not annoying, i am rational. > > 2. testing the stable minor releases makes no sense. we should be testing the release candidates of 4.11 > since its stable release is nearing. that would actually be beneficial to the users. the placing of stable > minor releases in testing is only delaying the distribution of the fixes to the users. > > also, AL users are expected to RTFM. AL is for advanced users and for people who are willing to learn how to > administrate their system(s). > > 3. he has known about it for many months. https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/ the above reply was rejected yesterday by little Florian for this reason: > The moderator gave the following reason for rejecting your request: > > "Your message was deemed inappropriate by the moderator." i know. it is so 'inappropriate' that Pope Francis would have died if he ever read it. now, on to the rest. about the '4+ days' thing. reread my message, carefully, because you have difficulties comprehending what i typed. hint: it is about delaying things for no good reason. two more maintenance examples, a recent Antonio Rojas one (once again, he edited today another imperfect PKGBUILD file and left it imperfect), and a Sébastien Luttringer one (an example of stupidity): https://git.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=pac… an md5 hash is still used and ftp.gnu.org is HTTPS-enabled. nevertheless, i must say that he has improved. https://git.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=pac… https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/sha256sums… he has learning difficulties. Carsten Mattner, yes, it is true. sometimes things break, but things can be fixed and there are ways to avoid breakage. RTFM and/or RTFW is a requirement.[1] also, because of evolution, each one of us possess a brain that can do 'miracles' when it is actually used. use it, people. i know that there are people for whom the activity of thinking is extremely painful, but we cannot stop 'rolling' because of them. in almost all cases it is the AL user's fault. if one is careless and clueless, bad things can and do happen. that is true almost everywhere, not only in system administration. - "They see me rollin', They hatin'!" (AL is a rolling release distro, and we want to (rock and) 'roll' forever) _ [1] https://wiki.archlinux.org/index.php/Pacman#Skip_package_from_being_upgraded https://wiki.archlinux.org/index.php/Pacman#Skip_package_group_from_being_u… https://wiki.archlinux.org/index.php/Pacman#Skip_files_from_being_installed… PS: Florian's censorship necessitated the use of a different address. any complaints about the message being out of the existing threads are invalid and remarks about my disposable email address are irrelevant. Florian, remove me immediately from 'moderation' to prove: 1. that you actually want to have an honest discussion about anything and everything, 2. that you are a decent person. PPS: whoever you are, you are so cute! port scanning my IP address yesterday, and today registering around with my name.

1 0

Re: [arch-general] End of official PaX and grsecurity support in Arch Linux
by Alexander Harrigan 29 Apr '17

29 Apr '17

I found someone from opensuse started to maintain grsec patches for 4.9 kernel series [1]. Maybe it will be possible to add linux-lts-grsec package to AUR based on Daniel's PKGBUILD and config with RANDSTRUCT enabled linked to new upstream source. [1] https://github.com/kdave/grsecurity-patches/tree/master/wip \-- Sent using MsgSafe.io's Free Plan Private, encrypted, online communication For everyone. https://www.msgsafe.io

2 1

[arch-general] Gnome crash
by Frank Zimmermann 29 Apr '17

29 Apr '17

Good evening, since yesterday my Gnome Shell crashes at start with the following message in the log: gnome-session-f[1207]: segfault at 0 ip 00007f01adab3cc9 sp 00007ffd261ce930 error 4 in libgtk-3.so.0.2200.6[7f01ad7d1000+6fa000] Is this a problem other Gnome users see as well? KR Frank

7 7

[arch-general] Arch Wiki Professional_audio
by Ralf Mardorf 28 Apr '17

28 Apr '17

Hi, the Wiki [ https://wiki.archlinux.org/index.php/Professional_audio ] opens with... "This article or section needs expansion." and a link to the discussion, but I still don't understand what actually is missing. ...followed by an unrealistic claim about grotesque low latency. The article included wrong information, I already removed "If you want to use any MIDI hardware you need to ensure the ALSA MIDI driver is loaded. You can set the MIDI driver to load at boot by creating the file /etc/modules-load.d/alsamidi.conf containing:" IIRC apart from a bug that caused that the driver wasn't loaded, the driver always gets loaded automatically. There are claims about rtc, 1000Hz. This was valid, but IMO should be obsolete now. Etc., pp. ... I don't want to rewrite the Wiki, especially because I won't and/or can't test every hint. Please contribute to the Wiki and/or to the "This and that" discussion [ https://wiki.archlinux.org/index.php/Talk:Professional_audio ]. Regards, Ralf

5 7

[arch-general] End of official PaX and grsecurity support in Arch Linux
by Daniel Micay 28 Apr '17

28 Apr '17

The PaX and grsecurity patches are no longer going to be public, so official support in Arch Linux has ended: https://grsecurity.net/passing_the_baton.php https://grsecurity.net/passing_the_baton_faq.php I'll be clearing out the AUR packages for PaX and grsecurity soon since the current 4.10 patches are not accessible. Providing out-of-date packages with known vulnerabilities and without the current set of mitigations is infringing on how they want their trademarks used. If people want to maintain forks, either a 4.9 LTS or porting it forward to newer kernels, they'll need to make a new project with a new name rather than using "PaX" or "grsecurity" as the naming. If it's serious and done by people that know what they're doing, official support for it can be considered. There are few people that are capable of truly taking over maintenance of the whole patches and I expect that they won't have time to do it. Don't be optimistic about this happening. There are no viable alternatives to PaX and grsecurity. Their focus is on kernel self-protection i.e. protecting the kernel from exploits, and we don't have anything for users to migrate to from these. There are plenty of alternatives to grsecurity RBAC but that's only a small portion of what the patches provide. Any form of access control (whether it's MAC, containers, uid/gid separation, ACLs, etc.) can be entirely bypassed with a single kernel exploit, so the only good way to use other MAC implementations like TOMOYO, AppArmor or SELinux was with grsecurity. We don't actually provide official support for any of these alternatives, but it's all little good without a hardened kernel anyway. A small subset of the kernel self-protection features have landed upstream as part of the Kernel Self Protection Project. The core/linux package doesn't enable the bulk of these features, and it probably doesn't make sense for it to turn everything on because a subset of them do have a significant performance cost. It would be possible to provide a linux-hardened package doing that but it would only offer a tiny portion of the kernel self-protection that grsecurity does. I may end up doing that, along with enabling support for all of the LSMs, etc. there but it's really not at all comparable to what has been lost. The LSMs are also little good without people working on providing userspace integration and policies for them. There are no good answers here. It would be possible to maintain a fork of grsecurity, especially if all kernel architectures other than x86_64 (and arm64, but it's not currently supported) were dropped along with grsecurity RBAC and anything that has a proper equivalent upstream. i386 and armv7 can still be supported as userspace archs, since dropping them as kernel archs is what would save most of the maintainance work and would eliminate a bunch of complex code only currently fully understood by the PaX and grsecurity authors. It might also make sense to start dropping support for old CPUs, beyond just only supporting 64-bit kernels. Intel Broadwell and later provide SMAP and there's also SMEP, so those could be used as substitutes for UDEREF and that portion of the KERNEXEC feature. The problem is that there aren't capable people with the time and willingness to dedicate a huge amount of their time to a volunteer project without pay. I already maintain/develop hardened Android LTS kernels as a significant but overall quite small part of CopperheadOS. It's not comparable to this because it's my job. I spend far more than 40 hours a week on CopperheadOS, and it's actually quite a relief to not need to worry about maintaining PaX and grsecurity for Arch Linux anymore especially since I had to do it on my own. I've been aware that the test patches becoming private was a very real possibility even before spender started talking about it on IRC weeks ago, so it's really not a surprise.

3 6