Re: Planned Outage: Copr upgrade - 2016-01-19 20:00 UTC
Dne 18.1.2016 v 15:28 Miroslav Suchý napsal(a): > > Planned Outage: Copr upgrade - 2016-01-19 20:00 UTC > > There will be an outage starting at 2016-01-19 20:00 UTC, which will last > approximately 1 hours. > > During the outage backend will stop processing new task and they will be > queued in frontend and processed just after the > outage. The outage is over. It took longer then expected due some problems. I will post tomorrow post-mortem on copr-devel mailing list with more details for those who are interrested in. During the upgrade several builds failed due problem with signing process. Please resubmit those builds. I apologize for the inconvenience. Mirek Suchy -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Testing chrony seccomp support
On Mon, Jan 18, 2016 at 3:51 AM, Florian Weimer wrote: > On 01/18/2016 11:02 AM, Nikos Mavrogiannopoulos wrote: > >> As Florian suggested it makes more sense to compartmentalize chrony so >> that only a small controlled part of it needs to run with seccomp. My >> recommendation, if you want to use libraries in the filtered code, make >> their authors aware of that, so that they document any changes in the >> used system calls, and if possible ask them to document the existing >> system calls used (e.g., similarly to: >> http://www.gnutls.org/manual/html_node/Running-in-a-sandbox.html ) > > Interesting. There is one huge caveat: > > | As well as an calls needed for memory allocation to work. > > glibc malloc can basically call *anything*. We don't know what the > future will bring. Currently, we use (off the top of my head, I haven't > checked): > > * sbrk > * mmap > * mprotect > * munmap > * mremap > * madvise > * futex > * open > * read > * close > > (In some cases, there is some sort of fallback, or errors are ignored > and the optimization does not happen.) > > Future versions might reasonably use: > > * sched_getcpu > * clone > * clock_gettime > * more open/read/close > * readlink > * whatever system calls are used for memory protection keys > * whatever system calls are used for restartable sequences > > I appreciate what you are trying to do, but those seccomp filters > totally break encapsulation. I have no idea how to support this > properly, in a sustainable way. It appears very difficult to do this > for independently evolving libraries. The sandstorm approach is striaghtforward: the disallowed things return -ENOSYS. glibc can handle that quite nicely, as long as you let existing stuff through. --Andy -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Bullet version bump
Thanks for telling me,
And efl is rebuilt accordingly.
- Original Message -
> Hi,
>
> I plan on building bullet-2.83 in rawhide this weekend. Bullet uses a
> soversion that's equal to the package version, so each bullet version
> bump requires a rebuild of all dependent packages.
>
> According to dnf, the following packages are affected:
>
> $ dnf --disablerepo=* --enablerepo=rawhide repoquery --source
> --whatrequires libBullet*
> bullet-2.82-7.fc24.src.rpm
> cyphesis-0.6.2-7.fc24.src.rpm
> efl-1.16.0-3.fc24.src.rpm
> gazebo-6.5.1-1.fc24.src.rpm
> vdrift-20141020-3.fc24.src.rpm
>
> I rebuilt the above packages locally, and everything except cyphesis
> built successfully. The cyphesis error looks like it's unrelated to
> bullet (some files are installed directly to %{_docdir} that are no
> longer picked up by the %doc macro).
>
> I will take care of doing the rebuilds in rawhide, and fix the cyphesis
> package.
>
> Rich
>
--
Ding-Yi Chen
Software Engineer
Globalization Group
DID: +61 7 3514 8239
Email: dc...@redhat.com
Red Hat, Asia-Pacific Pty Ltd
Level 1, 193 North Quay
Brisbane 4000
Office: +61 7 3514 8100
Fax: +61 7 3514 8199
Website: www.redhat.com
Red Hat, Inc.
Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC
Twitter: Red Hat APAC | Red Hat ANZ
LinkedIn: Red Hat APAC | JBoss APAC
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: bodhi - new update obsoleted an older update that had been submitted for stable
On Tuesday, 19 January 2016 at 18:06, Kevin Fenzi wrote: > On Tue, 19 Jan 2016 15:20:33 + > Richard Fearn wrote: > > > Hi > > > > > The same thing happened to me with mozilla-noscript updates that > > > were submitted to stable and obsoleted by another set of updates > > > I submitted to testing today. > > > > Glad to hear it's not just me :) > > > > > It's not different. Both F23 and F22 updates are affected in the > > > same way. > > > > My 6.4.3 F22 update didn't obsolete my 6.4.0 F22 update. > > I am not at all sure whats up here, but could one of you file a bodhi > ticket on it? This seems like a bug causing a change in behavior... > > I'll get Luke to look into it. https://github.com/fedora-infra/bodhi/issues/763 Thanks in advance. Regards, -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora Rawhide 20160119 compose check report
On Tue, 2016-01-19 at 16:43 +, Fedora compose checker wrote: > Missing expected images: > > Kde disk raw armhfp > Kde live i386 > Kde live x86_64 > > No images in this compose but not Rawhide 20160118 > > Images in Rawhide 20160118 but not this: > > Kde live i386 > Scientific_kde live x86_64 > Cloud_atomic vagrant virtualbox x86_64 > Scientific_kde live i386 > Cloud_atomic vagrant libvirt x86_64 > Kde live x86_64 > > Failed openQA tests: 4 of 63 > > ID: 3469 Test: x86_64 workstation_live base_services_start > URL: https://openqa.fedoraproject.org/tests/3469 Same ol', same ol' - the virtlogd bug should be fixed soon, though. > ID: 3424 Test: x86_64 universal package_set_kde > URL: https://openqa.fedoraproject.org/tests/3424 > ID: 3450 Test: i386 universal package_set_kde > URL: https://openqa.fedoraproject.org/tests/3450 These neatly explain why the KDE images are missing =) Some kind of dependency issue in the KDE package set. > ID: 3422 Test: x86_64 universal server_lvmthin > URL: https://openqa.fedoraproject.org/tests/3422 Looks to be a bogus failure, the install process got stuck for some reason. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Testing chrony seccomp support
On Tue, 2016-01-19 at 09:18 +, Petr Pisar wrote: > This is doomed even without seccomp because malloc(3) is not > async-signal-safe ;) It sems to work reliably for us, but yeah, to do it safely, we need to preallocate all the memory. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: seccomp support [was: Testing chrony seccomp support]
On Tue, 2016-01-19 at 10:16 +0100, Nikos Mavrogiannopoulos wrote: > The issue is that blacklists are terrible from a security standpoint. > That means that every new obscure system call added to the kernel > will > be available by default in your program. Yes. This implies that seccomp should not be the primary enforcement mechanism for a sandbox, unless you static link to your dependencies to prevent the syscalls from unexpectedly changing. (This is what Chrome does.) It is useful regardless to blacklist a few syscalls that you know your application really should not be using. kexec is probably the best example. > That does sound like a very fragile usage of seccomp indeed. It was a bad idea. :) > It could > be solved of course by using IPC to open a file rather than relying > on > the signal. The kernel provides a couple options here: it can kill the process when it calls open(), or it can send SIGSYS (in which case the only way for the file to be opened is via IPC to a less-constrained process; this is what we do), or it can notify another process via ptrace (which I have not investigated). > Then the question for programs wanting to use glibc and seccomp would > be, could libc keep the syscalls fixed for its wrapper of system > calls, Even simply documenting the possible syscalls would be helpful to programmers using seccomp, although apps are still going to break in the future. > or could we have filters which are applied to glibc's calls rather > than > system calls? I don't think so. seccomp filters are per-process. Michael -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: seccomp support [was: Testing chrony seccomp support]
On Tue, 2016-01-19 at 08:08 -0800, Andrew Lutomirski wrote: > One of these days I need to tidy up Sandstorm's seccomp policy and > factor > it into its own library. It's made a good showing for itself over > the last > year or so, and it's highly compatible. I would be quite interested in this! Michael -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: dnf still is unuseable
On Seg, 2016-01-18 at 07:37 -0500, Neal Gompa wrote: > On Mon, Jan 18, 2016 at 7:27 AM, Jonathan Wakely > wrote: > > On 18/01/16 07:05 -0500, Honza Šilhan wrote: > > > > > > yes, autoremoval issue could be either caused by bad packaging > > > [1] or when > > > you are > > > installing packages via yum or packagekit [2]. We are working on > > > better > > > integration > > > between DNF and PK so this could be fixed soon. At the meantime > > > use this > > > workaround [3]. > > > > > > It's a *terrible* workaround though. "Make a note of everything > > that > > gets installed using PK and then as root run dnf to mark them as > > userinstalled". A better workaround is "Don't use PK to install > > things, use DNF". Why bother using PK at all if you then have to go > > and run DNF commands for the same packages? You might as well just > > use > > DNF. > > > > Honestly, I wonder why we didn't just have PackageKit have a DNF > backend directly, instead. https://bugzilla.redhat.com/show_bug.cgi?id=1256108 except that don't found any bug . > It seems like we created some very weird > problems by having two independent package managers that can't even > talk to each other. Maybe we should just tell people to use yumex- > dnf, > since it just calls DNF APIs through dnfdaemon, and I believe those > transactions remain in sync. > > Doing things like having PK shell out to call dnf mark just makes > things really odd. -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: bodhi - new update obsoleted an older update that had been submitted for stable
On Tue, 19 Jan 2016 15:20:33 + Richard Fearn wrote: > Hi > > > The same thing happened to me with mozilla-noscript updates that > > were submitted to stable and obsoleted by another set of updates > > I submitted to testing today. > > Glad to hear it's not just me :) > > > It's not different. Both F23 and F22 updates are affected in the > > same way. > > My 6.4.3 F22 update didn't obsolete my 6.4.0 F22 update. I am not at all sure whats up here, but could one of you file a bodhi ticket on it? This seems like a bug causing a change in behavior... I'll get Luke to look into it. kevin pgpyah4dmhq9z.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora Rawhide 20160119 compose check report
Missing expected images: Kde disk raw armhfp Kde live i386 Kde live x86_64 No images in this compose but not Rawhide 20160118 Images in Rawhide 20160118 but not this: Kde live i386 Scientific_kde live x86_64 Cloud_atomic vagrant virtualbox x86_64 Scientific_kde live i386 Cloud_atomic vagrant libvirt x86_64 Kde live x86_64 Failed openQA tests: 4 of 63 ID: 3469Test: x86_64 workstation_live base_services_start URL: https://openqa.fedoraproject.org/tests/3469 ID: 3424Test: x86_64 universal package_set_kde URL: https://openqa.fedoraproject.org/tests/3424 ID: 3450Test: i386 universal package_set_kde URL: https://openqa.fedoraproject.org/tests/3450 ID: 3422Test: x86_64 universal server_lvmthin URL: https://openqa.fedoraproject.org/tests/3422 Passed openQA tests: 59 of 63 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: seccomp support [was: Testing chrony seccomp support]
On Tue, Jan 19, 2016, at 11:08 AM, Andrew Lutomirski wrote: > > On Jan 19, 2016 7:41 AM, "Colin Walters" wrote: > > > > > > > > On Tue, Jan 19, 2016, at 04:16 AM, Nikos Mavrogiannopoulos wrote: > > > > > The issue is that blacklists are terrible from a security > > standpoint. > > > That means that every new obscure system call added to the > > kernel will > > > be available by default in your program. > > > > https://github.com/seccomp/libseccomp/issues/11 > One of these days I need to tidy up Sandstorm's seccomp policy and > factor it into its own library. It's made a good showing for itself > over the last year or so, and it's highly compatible. Yes, https://git.gnome.org/browse/linux-user-chroot/commit/?id=8cee4ab7345f126d1dec55b7ca1f28e8090a58d3 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Specs using %define
On Thu, 2015-12-24 at 15:01 -0600, Jason L Tibbitts III wrote: > ardour4 (nphilipp) > gegl (deji, nphilipp) > gimp-data-extras (nphilipp) > gimp-help (nphilipp) > glade2 (nphilipp, alexl, caillon, caolanm, johnp, mbarnes, rhughes, rstrode, > ssp, group::gnome-sig) > python-augeas (xaeth, nphilipp) > rss-glx (nphilipp, cheese) > sane-backends (nphilipp) > supervisor (nphilipp, arg) > ufraw (nphilipp) fixed in git Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: seccomp support [was: Testing chrony seccomp support]
On Jan 19, 2016 7:41 AM, "Colin Walters" wrote: > > > > On Tue, Jan 19, 2016, at 04:16 AM, Nikos Mavrogiannopoulos wrote: > > > The issue is that blacklists are terrible from a security standpoint. > > That means that every new obscure system call added to the kernel will > > be available by default in your program. > > https://github.com/seccomp/libseccomp/issues/11 One of these days I need to tidy up Sandstorm's seccomp policy and factor it into its own library. It's made a good showing for itself over the last year or so, and it's highly compatible. --Andy -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: seccomp support [was: Testing chrony seccomp support]
On Tue, Jan 19, 2016, at 04:16 AM, Nikos Mavrogiannopoulos wrote: > The issue is that blacklists are terrible from a security standpoint. > That means that every new obscure system call added to the kernel will > be available by default in your program. https://github.com/seccomp/libseccomp/issues/11 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: dnf still is unuseable
Am Montag, den 18.01.2016, 07:05 -0500 schrieb Honza Šilhan: > > From: "James Hogarth" > > The autoremove reference might be the well known issue with > > packagekit, not > > dnf, that is not marking packages as installed rather than > > dependencies. > > > > The default dnf configuration is autoremove so that doesn't then > > know that > > have been specifically installed rather than just unneeded > > dependencies of > > something else and then helpfully tries to remove them... > > > > Note this is a result of a packagekit bug not dnf. > > > > On a side note it'd be nice if pk just called out to dnf so that > > they have a > > common backend which would prevent behaviour like this and would > > result in > > sharing a history database as well. > > yes, autoremoval issue could be either caused by bad packaging [1] or > when you are > installing packages via yum or packagekit [2]. We are working on > better integration > between DNF and PK so this could be fixed soon. At the meantime use > this workaround [3]. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1222812#c23 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1259865 > [3] http://dnf.baseurl.org/2015/10/26/mark-command-usecase/ That workaround is only useable if you know what packages you've installed via PK but because this issue exists nearly since a year that could be hard to remember what pacakges were installed via PK. -- Regards, Heiko Adams signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: dnf still is unuseable
Am 18.01.2016 um 13:39 schrieb Heiko Adams: Am Montag, den 18.01.2016, 12:27 + schrieb Jonathan Wakely: On 18/01/16 07:05 -0500, Honza Šilhan wrote: yes, autoremoval issue could be either caused by bad packaging [1] or when you are installing packages via yum or packagekit [2]. We are working on better integration between DNF and PK so this could be fixed soon. At the meantime use this workaround [3]. It's a *terrible* workaround though. "Make a note of everything that gets installed using PK and then as root run dnf to mark them as userinstalled". A better workaround is "Don't use PK to install things, use DNF". Why bother using PK at all if you then have to go and run DNF commands for the same packages? You might as well just use DNF. Because sometimes PK says there are updates available while "dnf update --refresh" says no updates are available? Happend to me several times in the past. that's the drawback of dnf-makecache.timer because it may cache something shortly before updates are pushed and without that caching it would be refresehd when it's attempted to be used and so contain recent data mask that timer and you are done that never should have been introduced as default the logflood "Cannot add dependency job for unit dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked" should go away soon (referenced in a different thread and a systemd bugreport of some otehr person) signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: dnf still is unuseable
Am 18.01.2016 um 13:16 schrieb Jonathan Wakely: And the fact that /var/log/dnf.rpm.log doesn't show updates done by PK is just annoying. Isn't there a single log file I can look at to see what was updated, and when? currently no because dnf, PK and yum-deprecated using different logging instead just point to a generic "/var/log/packages.log" or how ever called that's also annoying when you need to use yum-deprecated to get your tasks done, at least that and https://bugzilla.redhat.com/show_bug.cgi?id=1273925 could have been avoided (logwatch would have then contained the informations scratched with the premature logrotate) signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: bodhi - new update obsoleted an older update that had been submitted for stable
Hi > The same thing happened to me with mozilla-noscript updates that > were submitted to stable and obsoleted by another set of updates > I submitted to testing today. Glad to hear it's not just me :) > It's not different. Both F23 and F22 updates are affected in the same > way. My 6.4.3 F22 update didn't obsolete my 6.4.0 F22 update. Regards, Richard -- Richard Fearn richardfe...@gmail.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
REMINDER: Changes submission deadline for Fedora 24 in one week
Hi everyone! Fedora 24 Changes submission deadline [1] is coming in one week on January, the 26th. Alpha release is currently planned on March, the 15th. Please, submit your System Wide Changes by this deadline, earlier better. As the deadline mainly applies for System Wide Changes it is always good to have most of Self Contained Changes proposed as well. In case you'll need any help with your Change proposals, feel free to contact me. [1] https://fedoraproject.org/wiki/Releases/24/Schedule Best Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: dnf still is unuseable
On Mon, Jan 18, 2016 at 7:27 AM, Jonathan Wakely wrote: > On 18/01/16 07:05 -0500, Honza Šilhan wrote: >> >> yes, autoremoval issue could be either caused by bad packaging [1] or when >> you are >> installing packages via yum or packagekit [2]. We are working on better >> integration >> between DNF and PK so this could be fixed soon. At the meantime use this >> workaround [3]. > > > It's a *terrible* workaround though. "Make a note of everything that > gets installed using PK and then as root run dnf to mark them as > userinstalled". A better workaround is "Don't use PK to install > things, use DNF". Why bother using PK at all if you then have to go > and run DNF commands for the same packages? You might as well just use > DNF. > Honestly, I wonder why we didn't just have PackageKit have a DNF backend directly, instead. It seems like we created some very weird problems by having two independent package managers that can't even talk to each other. Maybe we should just tell people to use yumex-dnf, since it just calls DNF APIs through dnfdaemon, and I believe those transactions remain in sync. Doing things like having PK shell out to call dnf mark just makes things really odd. -- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Testing chrony seccomp support
On Mon, Jan 18, 2016 at 11:02:44AM +0100, Nikos Mavrogiannopoulos wrote: > As Florian suggested it makes more sense to compartmentalize chrony so > that only a small controlled part of it needs to run with seccomp. My > recommendation, if you want to use libraries in the filtered code, make > their authors aware of that, so that they document any changes in the > used system calls, and if possible ask them to document the existing > system calls used (e.g., similarly to: > http://www.gnutls.org/manual/html_node/Running-in-a-sandbox.html ) chronyd doesn't use libc for much more than that. There is memory allocation, reading/writing system clock, reading/writing/moving files, creating/connecting/binding sockets, receiving/sending packets, and select(). Name resolving is now out of the filter. The only other library that's currently used after the seccomp filter is loaded is freebl3 from NSS. I guess some of that could be moved to the helper process. If only the most dangerous code (whatever that is) should run with seccomp, I'm not sure if there is a layer where a clean small cut could be made. I suspect the interface between the two processes would be huge and it would bloat the code significantly. -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Any Alpine and Claws Mail users here?
On 01/19/2016 07:32 AM, Jiri Eischmann wrote: > Hi, > I'm writing an article on 6 most popular email clients in Fedora for > Fedora Magazine. For each client I'd like to have a quote from a Fedora > contributor why he/she is using that particular client. > I'm missing representatives of Alpine and Claws Mail. If you happen to > use them, can you please send me (off-list) a couple of sentences why? > > Those clients are mostly popular among technical people which is why > I'm trying devel list. > > > > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > I think Michael Scherer has mentioned usage of Claws. I tried to give it a try, but went back to Thunderbird because I'm getting old and curmudgeony. -J -- Jason E. Rist Senior Software Engineer OpenStack Infrastructure Integration Red Hat, Inc. openuc: +1.972.707.6408 mobile: +1.720.256.3933 Freenode: jrist github/twitter: knowncitizen -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Any Alpine and Claws Mail users here?
Hi, I'm writing an article on 6 most popular email clients in Fedora for Fedora Magazine. For each client I'd like to have a quote from a Fedora contributor why he/she is using that particular client. I'm missing representatives of Alpine and Claws Mail. If you happen to use them, can you please send me (off-list) a couple of sentences why? Those clients are mostly popular among technical people which is why I'm trying devel list. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: 4.3 rebase in F23 updates-testing
On Tue, Jan 12, 2016 at 3:02 PM, Josh Boyer wrote: > On Tue, Jan 12, 2016 at 2:08 PM, Mattia Verga wrote: >>> Please note there seem to be a btrfs regression in since 4.3: >>> namely fstrim could discard beginning of the disk, removing the >>> bootloader. This commit fixes the issue: >>> >>> >>> http://git.kernel.org/cgit/linux/kernel/git/fdmanana/linux.git/commit/?h=integration-4.5&id=7b6cb6618b45bb383f9336ec89df5f1f31f9935b > We'll pick up the fix once it lands in Linus' tree. Until then, the > safety is mostly determine by that of btrfs in general. Opinions > vary. FYI, I added the highlighted patch to F23 git today. It will be in the next build. josh -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: COPR repo in mock?
On 19/01/16 08:05 -0500, Nico Kadel-Garcia wrote: This has never worked. Please re-read the manual page for "mock" The "-r config" option finds "/etc/mock/config.cfg". The man page says: "Optionally if CONFIG ends in '.cfg', it is interpreted as full path to config file." And it works fine like that. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: COPR repo in mock?
On Tue, Jan 19, 2016 at 4:48 AM, Miroslav Suchy wrote: > Dne 19.1.2016 v 06:51 Dmitrij S. Kryzhevich napsal(a): >> Like any others. Provide information about repo to /etc/mock/YOURCONFIG.cfg >> In most cases in would be: /etc/mock/default.cfg >> >> You could find details for your particular copr repo in file with >> corresponding name in /etc/yum.repos.d dir if this repo already >> worldwide enabled in your system > > No need to put anything to /etc/mock. You can put it in your working > directory and not mess your /etc directory. > > So: > cp /etc/mock/fedora-23-x86_64.cfg ./myconfig.cfg > vim ./myconfig.cfg This has never worked. Please re-read the manual page for "mock" The "-r config" option finds "/etc/mock/config.cfg". There are actually some very real security reasons not to let mock pull arbitrary configuration files from local directories. It would provide way, way too much power to the local developer to build arbitrary chroot cages on the mock server, and to arbitrarily apply any build configuration they want, including setting the relevant mock cache and build directories to "/" and completely thrashing the server. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
rawhide report: 20160119 changes
Compose started at Tue Jan 19 05:15:02 UTC 2016 Broken deps for i386 -- [IQmol] IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2 [alliance] alliance-5.0-40.20090901snap.fc22.i686 requires libXm.so.2 [asterisk] asterisk-calendar-13.3.2-1.fc23.2.i686 requires libical.so.1 [avogadro] avogadro-libs-1.1.1-15.fc24.i686 requires libGLEW.so.1.10 [bes] bes-3.14.0-8.fc24.i686 requires libdap.so.17 [couchdb] couchdb-1.6.1-7.fc24.i686 requires erlang(erl_nif_version) = 0:2.7 couchdb-1.6.1-7.fc24.i686 requires erlang(erl_drv_version) = 0:3.1 [eclipse-jbosstools] eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires osgi(org.eclipse.tm.terminal) [ejabberd] ejabberd-14.07-6.fc22.i686 requires erlang(erl_nif_version) = 0:2.7 ejabberd-14.07-6.fc22.i686 requires erlang(erl_drv_version) = 0:3.1 [ekiga] ekiga-4.0.1-24.fc24.i686 requires libcamel-1.2.so.54 [erlang-basho_metrics] erlang-basho_metrics-1.0.0-15.fc23.i686 requires erlang(erl_nif_version) = 0:2.7 [erlang-bitcask] erlang-bitcask-1.6.3-6.fc22.i686 requires erlang(erl_nif_version) = 0:2.7 [erlang-ebloom] erlang-ebloom-2.0.0-2.fc23.i686 requires erlang(erl_nif_version) = 0:2.7 [erlang-eleveldb] erlang-eleveldb-1.3.2-7.fc22.i686 requires erlang(erl_nif_version) = 0:2.7 [erlang-emmap] erlang-emmap-0-0.12.git05ae1bb.fc23.i686 requires erlang(erl_nif_version) = 0:2.7 [erlang-esasl] erlang-esasl-0.1-18.20120116git665cc80.fc23.i686 requires erlang(erl_drv_version) = 0:3.1 [erlang-js] erlang-js-1.3.0-1.fc22.i686 requires erlang(erl_drv_version) = 0:3.1 [erlang-skerl] erlang-skerl-1.1.0-11.fc23.i686 requires erlang(erl_nif_version) = 0:2.7 [erlang-snappy] erlang-snappy-1.0.3-0.11.git80db168.fc23.i686 requires erlang(erl_nif_version) = 0:2.7 [evolution-rss] 1:evolution-rss-0.3.95-4.fc24.i686 requires libcamel-1.2.so.54 [fawkes] fawkes-core-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10 fawkes-plugin-player-0.5.0-26.fc24.i686 requires libgeos-3.4.2.so fawkes-plugin-xmlrpc-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10 [ffgtk] ffgtk-plugin-evolution-0.8.6-15.fc24.i686 requires libcamel-1.2.so.54 [gcc-python-plugin] gcc-python2-debug-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24 gcc-python2-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24 gcc-python3-debug-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24 gcc-python3-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24 [giggle] giggle-0.7-19.fc24.i686 requires libcamel-1.2.so.54 [glabels] glabels-3.2.1-5.fc24.i686 requires libcamel-1.2.so.54 [gnash] 1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:g
Re: Debugging practices and hardened packages
On 19/01/16 11:36, Jonathan Wakely wrote: On 19/01/16 11:10 +, Tom Hughes wrote: On 19/01/16 10:55, Jonathan Wakely wrote: Is there a way to tell it to ignore certain core files? I run parts of the GCC testsuite several times a day, and many of the tests are expected to call abort() to terminate. I don't want hundreds of them clogging up my journal, or being stored in ABRT. If you set RLIMIT_CORE to one byte (yes one, not zero) then the kernel won't send the core to the configured pipe at all. But that affects all cores, right? It looks like the path config Jakub suggested in his reply is what I want. Well all cores generated in an environment with that set, yes, I set it in my shells so I don't get cores when developing, but still get them when bits of my desktop crash because those were started from the gnome session which doesn't have it set. My problem wasn't that I got them, it was when using asan which has a vast but largely empty address space, which the kernel tried to pipe to abrtd in it's entirety because it ignores all core limits (except the special value of one) when dumping to a pipe. So the actual crashing program would be sat there for several minutes or more not actually exiting until the core dump was done while one CPU was spinning like mad in one of the abrt processes. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Debugging practices and hardened packages
On 19/01/16 12:32 +0100, Jakub Filak wrote: On 01/19/2016 11:55 AM, Jonathan Wakely wrote: On 19/01/16 11:00 +0100, Jakub Filak wrote: You do not need to disable abrtd (if you do that, you won't be able to send crash statistics to http://retrace.fedoraproject.org/). If you want to use coredumpctl, just disable abrt-ccpp.service and enable abrt-journal-core.service: http://abrt.readthedocs.org/en/latest/examples.html#getting-core-files-from-systemd-coredumctl Is there a way to tell it to ignore certain core files? I run parts of the GCC testsuite several times a day, and many of the tests are expected to call abort() to terminate. I don't want hundreds of them clogging up my journal, or being stored in ABRT. I cannot tell how it works in coredumpctl but ABRT C/C++ plugin can be configured to ignore any path (this feature will be available in ABRT 2.8 [1]). Right now, you can configure ABRT to drop core files of certain programs by adding program path to the BlackListedPaths option in /etc/abrt/abrt-action-save-package-data.conf [2] Thanks! -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Debugging practices and hardened packages
Am 19.01.2016 um 12:36 schrieb Tom Hughes: On 19/01/16 11:32, Jakub Filak wrote: I cannot tell how it works in coredumpctl but ABRT C/C++ plugin can be configured to ignore any path (this feature will be available in ABRT 2.8 [1]). Right now, you can configure ABRT to drop core files of certain programs by adding program path to the BlackListedPaths option in /etc/abrt/abrt-action-save-package-data.conf [2] It doesn't really help with the "big core dump" problem though because the kernel still sends the whole thing to the pipe and abrtd still sits there churning CPU for ages reading it out of the pipe, it just doesn't do anything with it then that's ABRT problem because systemd-coredump has no iusses with simply log that a coredump of eclipse with 3 GB process size was ignored signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Debugging practices and hardened packages
On 19/01/16 11:10 +, Tom Hughes wrote: On 19/01/16 10:55, Jonathan Wakely wrote: Is there a way to tell it to ignore certain core files? I run parts of the GCC testsuite several times a day, and many of the tests are expected to call abort() to terminate. I don't want hundreds of them clogging up my journal, or being stored in ABRT. If you set RLIMIT_CORE to one byte (yes one, not zero) then the kernel won't send the core to the configured pipe at all. But that affects all cores, right? It looks like the path config Jakub suggested in his reply is what I want. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Debugging practices and hardened packages
On 19/01/16 11:32, Jakub Filak wrote: I cannot tell how it works in coredumpctl but ABRT C/C++ plugin can be configured to ignore any path (this feature will be available in ABRT 2.8 [1]). Right now, you can configure ABRT to drop core files of certain programs by adding program path to the BlackListedPaths option in /etc/abrt/abrt-action-save-package-data.conf [2] It doesn't really help with the "big core dump" problem though because the kernel still sends the whole thing to the pipe and abrtd still sits there churning CPU for ages reading it out of the pipe, it just doesn't do anything with it. At least that was my experience when I tried to blacklist stuff in the past I think, which is why I came up with the one byte rlimit hack... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Debugging practices and hardened packages
On 01/19/2016 11:55 AM, Jonathan Wakely wrote: On 19/01/16 11:00 +0100, Jakub Filak wrote: You do not need to disable abrtd (if you do that, you won't be able to send crash statistics to http://retrace.fedoraproject.org/). If you want to use coredumpctl, just disable abrt-ccpp.service and enable abrt-journal-core.service: http://abrt.readthedocs.org/en/latest/examples.html#getting-core-files-from-systemd-coredumctl Is there a way to tell it to ignore certain core files? I run parts of the GCC testsuite several times a day, and many of the tests are expected to call abort() to terminate. I don't want hundreds of them clogging up my journal, or being stored in ABRT. I cannot tell how it works in coredumpctl but ABRT C/C++ plugin can be configured to ignore any path (this feature will be available in ABRT 2.8 [1]). Right now, you can configure ABRT to drop core files of certain programs by adding program path to the BlackListedPaths option in /etc/abrt/abrt-action-save-package-data.conf [2] Regards, Jakub 1: https://github.com/abrt/abrt/commit/fc9ea4b9608ec44c125a72ecbe76d6ccac48a137 2: http://abrt.readthedocs.org/en/latest/conf.html -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: bodhi - new update obsoleted an older update that had been submitted for stable
On Monday, 18 January 2016 at 20:03, Richard Fearn wrote: > Hi, [...] > Later I realised that the F23 6.4.3 update had obsoleted the F23 6.4.0 > update - hence why it had inherited the 6.4.0 bug and notes. > > I was surprised that this happened :) The same thing happened to me with mozilla-noscript updates that were submitted to stable and obsoleted by another set of updates I submitted to testing today. > I understand that I'd only *submitted* the 6.4.0 F23 update for > stable; it hadn't actually been *pushed* to stable when I created the > 6.4.3 update. But still, I have a couple of questions: > > 1) Is it sensible for an update, that has been submitted for stable, > to then be obsoleted by a subsequent update? I'd say it isn't. > 2) Why was the F23 behaviour different to the F22 behaviour? It's not different. Both F23 and F22 updates are affected in the same way. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Debugging practices and hardened packages
On 19/01/16 10:55, Jonathan Wakely wrote: Is there a way to tell it to ignore certain core files? I run parts of the GCC testsuite several times a day, and many of the tests are expected to call abort() to terminate. I don't want hundreds of them clogging up my journal, or being stored in ABRT. If you set RLIMIT_CORE to one byte (yes one, not zero) then the kernel won't send the core to the configured pipe at all. It's a bit of a hack really - it relies on the fact that when the kernel starts a process to pipe a core dump to it it deliberately sets the limit to one to avoid recursion if that process crashes. The main problem is that ulimit and most shells builtin limit commands take the core dump size limit in kB or other similar larger units but you can do it with setrlimit using a wrapper program I actually patch zsh to add a limitcore command that takes bytes as an argument so that I can block coredumps in my development windows as otherwise something like an asan abort tries to write a multi gigabyte coredump to abrt which doesn't end well, or rather doesn't end for a very long time... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Debugging practices and hardened packages
On 19/01/16 11:00 +0100, Jakub Filak wrote: You do not need to disable abrtd (if you do that, you won't be able to send crash statistics to http://retrace.fedoraproject.org/). If you want to use coredumpctl, just disable abrt-ccpp.service and enable abrt-journal-core.service: http://abrt.readthedocs.org/en/latest/examples.html#getting-core-files-from-systemd-coredumctl Is there a way to tell it to ignore certain core files? I run parts of the GCC testsuite several times a day, and many of the tests are expected to call abort() to terminate. I don't want hundreds of them clogging up my journal, or being stored in ABRT. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Debugging practices and hardened packages
On 01/14/2016 07:37 AM, Roman Tsisyk wrote: Hi, Fedora enables hardened builds [1] by default. This implies -fomit-frame-pointer -fstack-protector and -fPIE. [1]: https://fedoraproject.org/wiki/Packaging:Guidelines#PIE How it is supposed to be debugged by upstream developers? It would be nice to have **at least** a proper backtrace for crashed daemons. Even better to have a) coredump b) binary c) debug symbols for this version of binary. ABRT C/C++ plugin stores a) and can be configured to store also b) [1]. ABRT also provides tools for downloading debuginfo and creating reports in several destinations (Bugzilla, MantisBT, e-mail, ...) [2]. Otherwise I can't suggest to use such packages for the end users. Does ABRT [2] actually work? It depends. I think it just works, it needs some polishing though ;) Patches are more than welcome [3]. Who have experience with it on production? Is there somewhere a guide for sysadmins about a preferred way to produce meaningful bug reports with stripped hardened binaries? We can create one. What would you like find there? Would be something like this: https://wiki.centos.org/TipsAndTricks/ABRT good start? To produce a meaningful bug report you can play with *abrt* on command line or Problem Reporting (*gnome-abrt*) application. Regards, Jakub 1: https://github.com/abrt/abrt/wiki/CCpp-plugin 2: http://abrt.readthedocs.org/en/latest/index.html 3: https://github.com/abrt -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Debugging practices and hardened packages
You do not need to disable abrtd (if you do that, you won't be
able to send crash statistics to http://retrace.fedoraproject.org/).
If you want to use coredumpctl, just disable
abrt-ccpp.service and enable abrt-journal-core.service:
http://abrt.readthedocs.org/en/latest/examples.html#getting-core-files-from-systemd-coredumctl
Regards,
Jakub
On 01/14/2016 05:03 PM, Michael Catanzaro wrote:
You can use ABRT to manage your core dumps, but it's not as nice as
coredumpctl. I recommend disabling ABRT ('systemctl disable abrtd' and
'systemctl stop abrtd') so that your core dumps will appear in
coredumpctl. The ABRT developers are working on better coredumpctl
integration.
On Thu, 2016-01-14 at 13:39 +0300, Roman Tsisyk wrote:
Does it log stack traces with symbol names on crash?
It stores short stack traces with just function names in the system
journal. It stores core dumps temporarily until some size limit is hit,
so you don't have to worry about disk space. You can configure the
limits in /etc/systemd/coredump.conf. In practice this means you get
full stack traces for recent crashes, and simple traces for older ones.
'coredumpctl gdb' is great and you will enjoy it!
Michael
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: COPR repo in mock?
Dne 19.1.2016 v 06:51 Dmitrij S. Kryzhevich napsal(a): > Like any others. Provide information about repo to /etc/mock/YOURCONFIG.cfg > In most cases in would be: /etc/mock/default.cfg > > You could find details for your particular copr repo in file with > corresponding name in /etc/yum.repos.d dir if this repo already > worldwide enabled in your system No need to put anything to /etc/mock. You can put it in your working directory and not mess your /etc directory. So: cp /etc/mock/fedora-23-x86_64.cfg ./myconfig.cfg vim ./myconfig.cfg at the end of config_opts['yum.conf'] = """ [main] ... [updates-testing-debuginfo] ... enabled=0 """ put the content of copr repo file (before the """) e.g. ... enabled=0 [msuchy-spark-cli] name=Copr repo for spark-cli owned by msuchy baseurl=https://copr-be.cloud.fedoraproject.org/results/msuchy/spark-cli/fedora-$releasever-$basearch/ skip_if_unavailable=True gpgcheck=1 gpgkey=https://copr-be.cloud.fedoraproject.org/results/msuchy/spark-cli/pubkey.gpg enabled=1 """ and then just call: mock -r ./myconfig.cfg your.src.rpm Mirek -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Testing chrony seccomp support
On 2016-01-18, Michael Catanzaro wrote: > This all goes awry if, in the web process's signal handler, malloc > decides to call open(), This is doomed even without seccomp because malloc(3) is not async-signal-safe ;) -- Petr -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
seccomp support [was: Testing chrony seccomp support]
On Mon, 2016-01-18 at 09:51 -0600, Michael Catanzaro wrote: > > I appreciate what you are trying to do, but those seccomp filters > > totally break encapsulation. I have no idea how to support this > > properly, in a sustainable way. It appears very difficult to do > > this > > for independently evolving libraries. > > No matter what, any seccomp whitelist is doomed to break in the > future > if your program uses shared libraries (including glibc). I think > seccomp filters can reasonably be used with a blacklist of syscalls, > but not with a whitelist. The issue is that blacklists are terrible from a security standpoint. That means that every new obscure system call added to the kernel will be available by default in your program. > An anecdote: in WebKit (which has a seccomp filter sandbox not > compiled > by default, because it is unfinished and very fragile), the web > process > receives SIGSYS from seccomp when it calls open() or a related > function, which it does not have permission to use; it then passes > the > filename of the file it wants to open via IPC to a broker process, > which evaluates our filesystem policy, opens the file (if > permissible), > and sends the fd to the web process via a UNIX socket. This all goes > awry if, in the web process's signal handler, malloc decides to call > open(), triggering an infinite loop of SIGSYS handlers. So we have to > open all files used by malloc (currently > /proc/sys/vm/overcommit_memory > and /sys/devices/system/cpu/online) and cache the fds in the web > process before initializing seccomp filters. libseccomp could not > help > with that, since there are so many different ways to use seccomp; it > doesn't know anything about our broker processs. That does sound like a very fragile usage of seccomp indeed. It could be solved of course by using IPC to open a file rather than relying on the signal. In any case seccomp certainly requires a program to be restructured or designed in a way to have a limited to syscall requirements component to have seccomp enabled (e.g., only to glibc). If you cannot have that then seccomp is probably not the answer. Then the question for programs wanting to use glibc and seccomp would be, could libc keep the syscalls fixed for its wrapper of system calls, or could we have filters which are applied to glibc's calls rather than system calls? Otherwise the only remaining solution would be for applications requiring seccomp to switch to thinner libc variants. regards, Nikos -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
