[arch-general] possible root cause using Firefox
Today Firefox has crashed with the backtrace provided below when trying to view maps.google.com. While Firefox 45.0.2-1 was hanging I tried to invoke gdb with it: elm:~/bugs/arch-firefox-crash> ps ax | grep firefox 2655 ?Sl13:25 /usr/bin/firefox 3281 pts/2S+ 0:00 grep firefox elm:~/bugs/arch-firefox-crash> gdb -p 2655 GNU gdb (GDB) 7.11 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". Attaching to process 2655 ptrace: Die Operation ist nicht erlaubt. (gdb) It says "operation not permitted" here when trying to ptrace firefox which was launched just normally as always as user elm. Nonetheless it was possible to backtrace the hanging frifeox-instance as user root as you can see in the P.S.-section. There are two things which I would like to say about it: * Firefox did apparently not only crash but acquire root privileges by doing so; otherwise it would not have needed user root to backtrace firefox (there is no SELinux, Apparmor or anything else running here; it is a plain Arch-installation) * Secondly I believe it a shame that we do not have -debuginfo packages for Arch. This way any gathered backtrace - be it for security reasons or just for supporting developers - will be pretty useless. Anyone here who would consider to work on the debuginfo - issue? Finally I will have to say that I had noticed screen distortions before Firefox started to hang; consequently this could well be an issue related to GL/nouveau as well. Thanks for Your Attention, Elmar Stellnberger P.S.: here comes the backtrace; (Unfortunately I did not gather a core dump or anything else:) #0 0x7f67ddebcc3d in poll () from /usr/lib/libc.so.6 #1 0x7f67d8a3fae2 in ?? () from /usr/lib/libxcb.so.1 #2 0x7f67d8a41497 in ?? () from /usr/lib/libxcb.so.1 #3 0x7f67d8a415a1 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1 #4 0x7f67dc836727 in _XReply () from /usr/lib/libX11.so.6 #5 0x7f67dc81bc35 in XGetImage () from /usr/lib/libX11.so.6 #6 0x7f67d1cab8f0 in ?? () from /usr/lib/firefox/libxul.so #7 0x7f67d1cab7c8 in ?? () from /usr/lib/firefox/libxul.so #8 0x7f67d1caf7e5 in ?? () from /usr/lib/firefox/libxul.so #9 0x7f67d0e1d0b6 in ?? () from /usr/lib/firefox/libxul.so #10 0x7f67d1cacd59 in ?? () from /usr/lib/firefox/libxul.so #11 0x7f67d1cacbc3 in ?? () from /usr/lib/firefox/libxul.so #12 0x7f67d1656b78 in ?? () from /usr/lib/firefox/libxul.so #13 0x7f67d1cad9b3 in ?? () from /usr/lib/firefox/libxul.so #14 0x7f67d16604f3 in ?? () from /usr/lib/firefox/libxul.so #15 0x7f67cfc1635e in ?? () from /usr/lib/firefox/libxul.so #16 0x7f67cfc03033 in ?? () from /usr/lib/firefox/libxul.so #17 0x7f67cfc0af2d in ?? () from /usr/lib/firefox/libxul.so #18 0x7f67cfc0e254 in ?? () from /usr/lib/firefox/libxul.so #19 0x7f67cfc0314a in ?? () from /usr/lib/firefox/libxul.so #20 0x7f67cfc0ae98 in ?? () from /usr/lib/firefox/libxul.so #21 0x7f67cfc0c2b6 in ?? () from /usr/lib/firefox/libxul.so #22 0x7f67cfc0314a in ?? () from /usr/lib/firefox/libxul.so #23 0x7f67cfc0ae98 in ?? () from /usr/lib/firefox/libxul.so #24 0x7f67cfc0c3d8 in ?? () from /usr/lib/firefox/libxul.so #25 0x7f67cfc0314a in ?? () from /usr/lib/firefox/libxul.so #26 0x7f67cfc0ae98 in ?? () from /usr/lib/firefox/libxul.so #27 0x7f67cfc0c338 in ?? () from /usr/lib/firefox/libxul.so #28 0x7f67cfc0314a in ?? () from /usr/lib/firefox/libxul.so #29 0x7f67cfbff18d in ?? () from /usr/lib/firefox/libxul.so #30 0x7f67cfc2b352 in ?? () from /usr/lib/firefox/libxul.so #31 0x7f67d0a3ba01 in ?? () from /usr/lib/firefox/libxul.so #32 0x7f67d0a413ad in ?? () from /usr/lib/firefox/libxul.so #33 0x7f67d0a4757c in ?? () from /usr/lib/firefox/libxul.so #34 0x7f67d15325a8 in ?? () from /usr/lib/firefox/libxul.so #35 0x7f67d1530f0a in ?? () from /usr/lib/firefox/libxul.so #36 0x7f67d133768b in ?? () from /usr/lib/firefox/libxul.so #37 0x7f67d13363fc in ?? () from /usr/lib/firefox/libxul.so #38 0x7f67d133441c in ?? () from /usr/lib/firefox/libxul.so #39 0x7f67d1531f52 in ?? () from /usr/lib/firefox/libxul.so #40 0x7f67d1530b59 in ?? () from /usr/lib/firefox/libxul
Re: [arch-general] Thinkpad 770 - Init exists but couldn't execute it (error -26)
Am 2016-04-10 um 21:29 schrieb Serge Hooge: The CD boots okay, but when I try to actually boot x86 Arch, it Kernel Panics with the subject title. It tries /bin/init, /sbin/init and /bin/sh, failing with the same message for all of them. Some searching shows that ERRNO 26 is for a busy file, but I've no clue what may be accessing all the init files at the time of the boot. I tried passing init=/usr/lib/systemd/systemd, but it fails with error -2. Is systemd not on the CD? I have read about successful installations of Arch on this machine previously, but they mentioned no problems of the sort, presumably that was pre-systemd Arch. Is there anything else I could try to get it working? I am using a late 2015 ISO for the CD. Is there any error message when it tries to mount the root file system? Likely yes; so the problem would be that your initrd does not contain the right drivers for disk access. * reboot with the CD * adjust /etc/mkinitcpio.conf The HOOK line looks at me like the following: HOOKS="base udev modconf block filesystems keyboard fsck resume" Try to remove 'autodetect'; it may strip modules that are needed by accident; 'resume' is necessary for s2disk. * re-create your initrd mkinitcpio -k YOURKERNELVER -g /boot/initramfs-linux.img KERNELVER can be found out by ls /lib/modules Good Luck! P.S.: these things are also explained under: http://www.elstel.org/software/hunt-for-4K-UHD-2160p.html.en#kernel
[arch-general] SSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird)
While being connected via an insecure VPN I had once more left my email client open by accident (Thunderbird). Though access to imap.gmail.com shall be secured by SSL/TLS my gmail password was malversated within a few seconds; i.e. I got a login attempt from HongKong and had to change the password after disconnecting. Is anyone here who can explain the insecurity of SSL/TLS in its current state? Does Thunderbird support certificate pinning? Or do you think that there are still errors in the implementation of the protocol? What about libressl for Linux?
Re: [arch-general] btrfs/snapper hook for pacman 5.0?
Am 2016-02-02 um 14:53 schrieb Karol Babioch: Hi, Am 02.02.2016 um 14:15 schrieb Elmar Stellnberger: However you may implement this feature please make sure that it takes care of the availabel disk space! Most people do only have limited space on their root partition and by making numerous snapshots your hard drive will be clobbered soon. Besides this the feature should stop automatically or ask for elder snapshots to be deleted before the max. drive fill reaches a certain percentage (f.i. 80%). As soon as your root partition gets filled by 100% you may not even be able to boot from it. The good thing is that snapper is taking care of most of these issues. It will automatically remove snapshots (according to your configuration). pacman is also checking for available disk space before doing the upgrade. So for all practical means the combination of both should be good enough. Best regards, Karol Babioch Hi all, The problem about it is that when a new snapshot is created no additional disk space becomes consumed immediately. Only on change of the given files a possibly huge amount of disk space can get allocated by Copy On Write. The problem about it is that the update tool does not know that changing one byte in file X will result in a full copy of that file structure and block. I am saying this because I have already run into the 100% disk space consumed issue with snapper and openSUSE a couple of years ago. Elmar
Re: [arch-general] btrfs/snapper hook for pacman 5.0?
However you may implement this feature please make sure that it takes care of the availabel disk space! Most people do only have limited space on their root partition and by making numerous snapshots your hard drive will be clobbered soon. Besides this the feature should stop automatically or ask for elder snapshots to be deleted before the max. drive fill reaches a certain percentage (f.i. 80%). As soon as your root partition gets filled by 100% you may not even be able to boot from it. Honestly thinking I can imagine there being an automatic restoration point for the last update only many consecutive updates being condensed for the same auto-restoration point on a single day, only. Anyway please do not leave many automatic restoration points hanging around. Elmar
Re: [arch-general] opinion request about Firefox add-ons
Am 2016-01-31 um 17:45 schrieb Francis Gerund: Hi. Firefox 44.0 does not seem to allow installing the firefox-adblock-plus addon package from the Arch community repository. Instead, Firefox states that it only allows addons "signed" by Mozilla to be installed. That seems to exclude the package mentioned. I could install the adblock-plus addon version available from Mozilla, directly through Firefox. But is this okay, or a bad idea, or is there a better idea? Any opinions? Well, I would personally also like to see the most used as well as some security relevant Firefox addons to be packaged including AdBlock Plus, the Extended DNSSEC Validator, a good http2https plugin and possibly even FireFTP and Flagfox. Though all these addons should to my believe be available via https getting them looked after and signed by the Arch security team would certainly improve the security when using Firefox. Besides this I would suggest some improvements in the default settings so that users may enjoye a more secure browsing experience. However the question always remains on how readily Arch maintainers would adopt these suggestions. P.S.: what about uBlock Origin; is it better/simpler/more secure than AdBlock Plus? perhaps get this one pre-packaged instead of AdBlock Plus.
Re: [arch-general] [arch-security] [Announcement] Discussion about restricting arch-security for public participation
In my opinion I don't feel like we are urged to have a separate list as most of the time the topics blur the line and splitting it does not provide much benefit. Distributions tend to have own security lists so that people can receive security related stuff, only. To me there is simply too much irrelevant traffic with regards to security related topics on the arch-general list. Getting posts about imminent and potential security risks from many different sides is f.i. something I still estimate about the Debian security list very much. Besides the fact that many people from the security list previously also open for discussion will not participate in a discussion here I wanna say that I would still estimate an own list for security discussion if not achieving the current security list to be opened up for posts from various sides again. If you do not want any discussion there simply rename this list from "Discussion about security issues in Arch" into "Security Announcements for Arch". Then it will be clear to everyone that this list is not for posing security related questions or just having a discussion. Am 2016-01-28 um 17:29 schrieb Levente Polyak: > On 01/28/2016 04:29 PM, Elmar Stellnberger wrote: >> >P.S. Slightly off-topic: my sincerest gratitude to everyone behind the >> >security announcements! You're doing a great job, and this is not just >> >empty words. >> > > Thank you very much, that is appreciated and makes us happy... however > to be pedantic: Most of the work needs to be done before any > announcements, that is just the (smallest) final step:) No doubt, the Arch as well as other indipendent security teams are currently doing a great job! It needs to be said twice. Nonetheless there are two things that should be mentioned: First of all if there is something that I keep estimating most about the many Open Source communities then it is people always being open for contribution, input and discussion from various sides. Secondly we can not suggest to people that they are in a safe place just because they are using up to date OSS software by the time. Many serious and dire security vulnerabilities (leading f.i. to arbitrary code execution or privilege escalation) have recently been closed not just in the Chrome and Firefox browser but there may very likely be further issues; i.e. keep your work going, I just wanna see a more secure OSS environment for the future! Elmar
Re: [arch-general] [arch-security] [Announcement] Discussion about restricting arch-security for public participation
Now there are different opinions about this: Some people certainly estimate comments, questions and discussion about security issues which do not solely pertain to updates of packages for already known security issues. Allowing discussion about potential security risks is also an important issue though certain package maintainers and arch-security personnel may feel discomforted about such discussions. Nonetheless I would believe such discussion to be worthwhile and important. Those who do not want to read it will not need to as soon as we have separate lists for "Discussion about security issues in Arch" and "Package updates for Arch resolving already known security issues". Just read f.i. the following message from Luchesar V. ILIEV: Weitergeleitete Nachricht Betreff: Re: [arch-security] strange netstat connections after having opened Firefox Datum: Sat, 5 Dec 2015 15:46:32 +0200 Von: Luchesar V. ILIEV <luchesar.il...@gmail.com> Antwort an: Discussion about security issues in Arch Linux and its packages <arch-secur...@archlinux.org> An: Discussion about security issues in Arch Linux and its packages <arch-secur...@archlinux.org> On 5 December 2015 at 14:01, Christian Rebischke <chris.rebisc...@archlinux.org> wrote: > This mailinglist has a daily-business todo and was not designed for > discussions. [...] The list name however says "Discussion about security issues in Arch Linux and its packages". That being said, I understand what you mean and agree with it. > [...] This mailinglist's main task is to > inform subscribers about newest vulnerabilities. So, could perhaps the list be split into two: one list for security-related discussions and one---moderated or even "read-only"---strictly for security announcements? For example, FreeBSD has these: freebsd-security: Security issues [members-only posting] freebsd-security-notifications: Moderated Security Notifications [moderated, low volume] The rationale is probably obvious. On one hand, people indeed expect a list used for security announcements to be used _only_ for this. Some might, for example, have set filters that mark such messages as urgent, display nagging pop ups, etc. On the other hand, the plain old e-mail still has value as a media for discussions. For example, it's not very practical to digitally sign forum postings, and IRC is a wholly different type of communication that might not always be appropriate. Cheers, Luchesar P.S. Slightly off-topic: my sincerest gratitude to everyone behind the security announcements! You're doing a great job, and this is not just empty words. Am 2016-01-28 um 13:06 schrieb Elmar Stellnberger: I see that there is certain interest in separating messages about security updates in given packages from general security discussions and announcements. Nonetheless if the arch-security list becomes closed down for public participation then we are in need of a new list for the latter two purposes. Am 2016-01-28 um 01:41 schrieb Levente Polyak: Dear arch-security subscribers, Dear arch-general subscribers, the policy of the arch-security mailinglist is currently changed to a restricted advisory announcements only list due to certain reason roughly explained on the arch-devops [0] and arch-dev-public [1] lists. As there was no announcement and discussion about this change yet, we want to invite you to discuss the restriction of the arch-security mailinglist on the CC-ed arch-general list. After making sure you are subscribed to arch-general [2], you can simply reply to this announcement by posting directly to the arch-general mailinglist. Our main goal behind this change is to separate relevant official announcements and advisories from possibly long and frequent discussions. The security teams idea is that each announcement to the arch-security list should be considered as an urgent alert and reviewed as soon as possible, without the need to filter them from general conversations and exchange of "unverified" information. sincerely, Levente (anthraxx) [0] https://lists.archlinux.org/pipermail/arch-devops/2016-January/07.html [1] https://lists.archlinux.org/pipermail/arch-dev-public/2015-December/027581.html [2] https://lists.archlinux.org/listinfo/arch-general
Re: [arch-general] [arch-security] [Announcement] Discussion about restricting arch-security for public participation
I see that there is certain interest in separating messages about security updates in given packages from general security discussions and announcements. Nonetheless if the arch-security list becomes closed down for public participation then we are in need of a new list for the latter two purposes. Am 2016-01-28 um 01:41 schrieb Levente Polyak: Dear arch-security subscribers, Dear arch-general subscribers, the policy of the arch-security mailinglist is currently changed to a restricted advisory announcements only list due to certain reason roughly explained on the arch-devops [0] and arch-dev-public [1] lists. As there was no announcement and discussion about this change yet, we want to invite you to discuss the restriction of the arch-security mailinglist on the CC-ed arch-general list. After making sure you are subscribed to arch-general [2], you can simply reply to this announcement by posting directly to the arch-general mailinglist. Our main goal behind this change is to separate relevant official announcements and advisories from possibly long and frequent discussions. The security teams idea is that each announcement to the arch-security list should be considered as an urgent alert and reviewed as soon as possible, without the need to filter them from general conversations and exchange of "unverified" information. sincerely, Levente (anthraxx) [0] https://lists.archlinux.org/pipermail/arch-devops/2016-January/07.html [1] https://lists.archlinux.org/pipermail/arch-dev-public/2015-December/027581.html [2] https://lists.archlinux.org/listinfo/arch-general
