Re: F24 GStreamer zero day
On 11/23/2016 10:15 PM, carl...@gnome.org wrote: But memory, I beg to differ :). Running on massif a from-scratch indexing of this laptop's homedir, tracker-store peaks at 16MB and runs under half of that for 67/69 snapshots. tracker-miner-fs peaks at 13MB and sits on half of that afterwards. What about the impact on kernel caches? The additional activity will evict things which would otherwise be used by foreground processes. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Add new application to repository
Hi all, I'm a newbie, so I don't know what are the steps to add a new application to the official repository. I'm asking this question because I ported Slingscold (fork of Slingshot, the Elementary OS application launcher) from GTK2 to GTK3 (project link: https://github.com/echo-devim/slingswarm). I'd like to add it to the Fedora official repository, but I don't know how to do that and if there are some requirements. Can someone help me, please? Kind regards, Gregorio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
dist.upgradepath FAILED for perl-DBD-MySQL-4.039-1.fc24
dist.upgradepath FAILED for perl-DBD-MySQL-4.039-1.fc24 https://taskotron.fedoraproject.org/artifacts/all/d6fd8a9a-b225-11e6-bf8c-525400120b80/task_output/perl-DBD-MySQL-4.039-1.fc24.log ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Re: Add new application to repository
Gregorio, you should read this https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=PackageMaintainers/Join чт, 24 нояб. 2016 г. в 12:11, Gregorio . : > Hi all, > > > I'm a newbie, so I don't know what are the steps to add a new application > to the official repository. I'm asking this question because I ported > Slingscold (fork of Slingshot, the Elementary OS application launcher) from > GTK2 to GTK3 (project link: https://github.com/echo-devim/slingswarm). > I'd like to add it to the Fedora official repository, but I don't know how > to do that and if there are some requirements. > > > Can someone help me, please? > > > Kind regards, > > Gregorio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F24 GStreamer zero day
Hi, On 23-11-16 22:15, carl...@gnome.org wrote: Hi Hans, (Talking with my Tracker maintainer hat) Hi, On 23-11-16 15:36, Michael Catanzaro wrote: I don't think that is entirely true. I've recently been trying to get gnome3 to run on under-powered machines like cheap ARM tablets, and I can do "dnf remove tracker" more or less just fine, I loose totem due to some weird dependency chain, and I think also gnome-documents which I guess is an issue for some use-cases, but most of gnome will stay and work just fine. I think that is rather short sighted, although tracker overall does well with not hogging the system it is still simply too heavy for some systems, both in memory use and in generated IOs, take e.g. GNOME3 on a raspberry pi running from a sdcard, there you really don't want tracker, so if you say: I can see how Tracker's extra involved I/O may become noticeable in such hw/scenarios (mainly coming from tracker-miner-fs I presume), it roots in inotify being notoriously bad for indexers... The problem we've at the moment is basically that we perform pretty poorly on resource constrained devices, part of that is a shitload of running services (on a 512MB device I need to disable gdm and use startx because running gdm + gnome-shell together results in swapping which is very painful on a sdcard). My "solution" for that is to just dnf remove a whole bunch of stuff, tracker only being one of them. I must admit I've never noticed a problem specifically caused by tracker, the whole experience just sucks, so I've pretty much been disabling everything I can. I would prefer a better solution, but given how very bad sdcards typically are at random access, something like tracker really _might_ be a problem. Question which directories does tracker actually scan / monitor by default ? But memory, I beg to differ :). Running on massif a from-scratch indexing of this laptop's homedir, tracker-store peaks at 16MB and runs under half of that for 67/69 snapshots. tracker-miner-fs peaks at 13MB and sits on half of that afterwards. In short only tracker-extract is "expected" to misbehave memory-wise (due to third party libraries, bugs, leaks in those, ...). The other daemons are rather moderate in memory consumption, although maybe seen over the "I can do without this" prism, sure looks like a waste ;). Worth pointing out too, tracker-extract had for years a hard memory limit, so if anything asked too much memory, tracker-extract would crash and be eventually (re)started at some point. I ended up removing it because the many bogus retrace reports, the many "it didn't index this super-important file" complains and because some file/library combinations actually needed more memory than given (poppler, if you wonder). If a library leaks or allocates too much memory, it's a bug in the library and should be fixed there, or so I thought :). Is that memory limit still there, but configurable and disabled now, or ? Can we re-instantiate it ? I would really like to be able to offer close to the full gnome3 experience on resource constrained devices, so I'm wondering if tracker can be configured to behave a bit nicer there. Maybe we can even get it to autodetect such systems. E.g. re-instate the hardlimit on systems with less then 1GB of RAM ? Regards, Hans "I don't think we'll support running without tracker anytime soon." I read: "I don't think we will have a usable GNOME3 on the Raspberry Pi anytime soon." Tracker comes from the mobile world, it has been used several times there with success, and has a number of gsettings that allow it to accommodate to very different workloads (most of them sacrificing instantness for reduced resources). But Tracker is, by default, optimized for the desktop. It would be nice if Tracker worked better out of the box on those setups, however I'd rather put all my fish on the "fix file notification" pan, as that's IMHO the key to making Tracker a single size for all. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Add new application to repository
On Thu, Nov 24, 2016 at 10:10 AM, Gregorio . wrote: > Hi all, Hello, > > > I'm a newbie, so I don't know what are the steps to add a new application to > the official repository. I'm asking this question because I ported > Slingscold (fork of Slingshot, the Elementary OS application launcher) from > GTK2 to GTK3 (project link: https://github.com/echo-devim/slingswarm). I'd > like to add it to the Fedora official repository, but I don't know how to do > that and if there are some requirements. > > > Can someone help me, please? https://fedoraproject.org/wiki/Join_the_package_collection_maintainers > > > Kind regards, > > Gregorio > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Add new application to repository
Dne 24.11.2016 v 10:10 Gregorio . napsal(a): > Hi all, > > > I'm a newbie, so I don't know what are the steps to add a new application to > the official repository. I'm asking this > question because I ported Slingscold (fork of Slingshot, the Elementary OS > application launcher) from GTK2 to GTK3 > (project link: https://github.com/echo-devim/slingswarm). I'd like to add it > to the Fedora official repository, but I > don't know how to do that and if there are some requirements. > > > Can someone help me, please? https://fedoraproject.org/wiki/Join_the_package_collection_maintainers -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F24 GStreamer zero day
Hi, > On Wed, Nov 23, 2016 at 5:03 PM, Carlos Garnacho wrote: > > I'm objecting to whatever piece of software opens thoroughly untrusted > files out of ~/Downloads and parses them. If that's not "Tracker", > then I apologize. > > > Firefox is a big piece of code that loads untrusted stuff. It's > written in a memory-unsafe language, and there's a big team working on > fixing that. It's not sandboxed, and there's a project to fix that. > And it's still a major attack vector, but at least it has a very > serious security team. Sounds great, do they also get the blame for gstreamer bugs? I've got lots of fun so share ;). According to you Firefox is just as insecure, and I can tell that Firefox uses GStreamer to open untrusted content over the internet. Why downloading the file at all, you could be tricked into a webpage that auto-plays the infected content, it could even be an ad unbeknownst by the site, you got every bit as infected and Tracker wasn't involved, using the exact piece of sofware as attack vector that we're talking nowadays. Actually, nice comparison, Tracker and Firefox share 90% of the underlying 3rd party libraries to implement support for every format (jpegs, gifs, pdfs, videos, you name it), whatever security bug is found in those libraries will affect Firefox and Tracker equally. And as for the projects themselves, Tracker is a fraction of Firefox in terms of code size, and tracker-extract inside Tracker is another fraction. That makes a whole lot difference between auditing or securing a *web engine* and a process that essentially iterates over files. Why is Firefox then any more credible? Must be the serious looks of their security team. > > The fact that flatpak integration is being planned is great. I hope > that flatpak has an exceedingly strict mode for applications like > this. > > Tracker is just as exposed as Firefox because it (or some piece of it > or whatever) parses stuff in Downloads. Tracker-extract is not as exposed as Firefox, because the file needs being in the local filesystem for starters. The web world is well known for figuratively throwing 3rd party media content to your face, even in otherwise trusted websites. Anyway, the dead horse took its beating, things won't get done just talking, I'm back to work. Cheers, Carlos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Add new application to repository
Ok, thank you! Kind regards, Gregorio From: Miroslav Such? Sent: Thursday, November 24, 2016 10:16:22 AM To: devel@lists.fedoraproject.org Subject: Re: Add new application to repository Dne 24.11.2016 v 10:10 Gregorio . napsal(a): > Hi all, > > > I'm a newbie, so I don't know what are the steps to add a new application to > the official repository. I'm asking this > question because I ported Slingscold (fork of Slingshot, the Elementary OS > application launcher) from GTK2 to GTK3 > (project link: https://github.com/echo-devim/slingswarm). I'd like to add it > to the Fedora official repository, but I > don't know how to do that and if there are some requirements. > > > Can someone help me, please? https://fedoraproject.org/wiki/Join_the_package_collection_maintainers -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F24 GStreamer zero day
> On 11/23/2016 10:15 PM, carlosg(a)gnome.org wrote: > > > What about the impact on kernel caches? The additional activity will > evict things which would otherwise be used by foreground processes. Tracker processes call sched_setscheduler/ioprio/nice to lower their priorities to a minimum, that's as educated as you can get from userspace. And anyway... tracker-miner-fs sits idle 99% of the time, every activity is punctual and finite, but of course dependent on your own activity in the inspected folders. Cheers, Carlos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
bsh-2.0-1.b6.fc26 license change
bsh-2.0-1.b6.fc26 license was changed from "(SPL or LGPLv2+) and Public Domain" to "ASL 2.0 and BSD and Public Domain" ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F24 GStreamer zero day
Hi, > Hi, > > On 23-11-16 22:15, carlosg(a)gnome.org wrote: > > The problem we've at the moment is basically that we perform > pretty poorly on resource constrained devices, part of that > is a shitload of running services (on a 512MB device I need > to disable gdm and use startx because running gdm + > gnome-shell together results in swapping which is very > painful on a sdcard). Oh, sure. Obviously the mobile scenarios I'm talking about didn't have that many processes running, nor multi-user setups. However, this is not a Tracker problem per se, rather a general one about minimum required memory to run a multi-user ready full-blown gnome desktop. > > My "solution" for that is to just dnf remove a whole bunch > of stuff, tracker only being one of them. > > I must admit I've never noticed a problem specifically caused > by tracker, the whole experience just sucks, so I've pretty > much been disabling everything I can. Well, if you concretize and turn into upstream bugs, I'll look into it. That's all I can tell :). > > I would prefer a better solution, but given how very bad sdcards > typically are at random access, something like tracker really > _might_ be a problem. > > Question which directories does tracker actually scan / monitor by > default ? XDG folders recursively, $HOME non-recursively. This is all configurable in the privacy pane in the control-center fwiw. > > > Is that memory limit still there, but configurable and disabled > now, or ? > > Can we re-instantiate it ? I would really like to be able > to offer close to the full gnome3 experience on resource > constrained devices, so I'm wondering if tracker can be > configured to behave a bit nicer there. Maybe we can even > get it to autodetect such systems. E.g. re-instate the > hardlimit on systems with less then 1GB of RAM ? It can be restablished, I'm not sure you'd enjoy the extra abrtd activity when tracker-extract "crashes" though :/, unless you disabled that too, that is... I guess I can make it check low-resources scenarios and try to do the best out of the box wrt i/o and cpu. But memory-wise I still think the best I can do is valgrinding the hell out of it, and file bugs to leaky libraries [1], as I've done over the years. Cheers, Carlos [1] https://bugzilla.gnome.org/show_bug.cgi?id=748608 comes to mind ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Bug 987118] perl-5.18: File handles modified with binmode ':unix' leak
https://bugzilla.redhat.com/show_bug.cgi?id=987118 Jitka Plesnikova changed: What|Removed |Added Version|23 |24 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
The Fedora Prioritized bugs and issues process
Hi everybody, as discussed in [1] email thread, we are starting the "Fedora Prioritized bugs and issues process" [2]. The main goal is to identify and make more visible bugs and issues which have critical impact on a Fedora Edition or on a council-approved Fedora Objective. We will start with our first evaluation meeting on Wednesday November the 30th, 2016 at 15:00 UTC on #fedora-meeting IRC channel [3]. I will be happy if people interested in participation on the evaluation will let me know, so we can setup the initial Evaluation team. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IGT4TGHJZK6442JM4VLBRSPCW6DKTUPI/ [2] https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues_-_the_process [3] https://apps.fedoraproject.org/calendar/Fedora%20release/2016/11/28/#m5154 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 To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F24 GStreamer zero day
On 11/24/2016 11:27 AM, Carlos Garnacho wrote: On 11/23/2016 10:15 PM, carlosg(a)gnome.org wrote: What about the impact on kernel caches? The additional activity will evict things which would otherwise be used by foreground processes. Tracker processes call sched_setscheduler/ioprio/nice to lower their priorities to a minimum, that's as educated as you can get from userspace. I don't think this has any impact on caches. I'm not even sure how effective cgroups would be to make sure that the indexing activity doesn't disturb the rest of the system. Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: HEADS UP: eigen-3.3.0 update
On Wednesday, 23 November 2016 at 22:45, Sandro Mani wrote: > Hi > > eigen-3.3.0 was released a a couple of weeks ago, and I've investigated the > consequences of updating in rawhide in this [1] COPR repo. The detailed > analysis is below, the summary is: > > - five dependent packages fail to build due to the eigen3 update: avogadro, > ceres-solver, kalzium, shogun and tapkee > - of these, ceres-solver, shogun and tapkee can be fixed by upgrading to > newer versions (first two) or backporting upstream fixes (tapkee) > - (The shogun update needs viennacl which is stalled in review [2]) > - avogadro relies on the eigen-2.x compatibility which was removed in > eigen-3.3, and there is not progress upstream so far in resolving the issue. Why not unretire eigen2 and build avogadro against that? Or does it use eigen3 features as well? 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 To unsubscribe send an email to devel-le...@lists.fedoraproject.org
rubygem-hashery license changed to BSD
rubygem-hashery-2.1.2-1.fc26 changed it's license from MIT to BSD. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F24 GStreamer zero day
On Thu, 2016-11-24 at 10:02 +, Carlos Garnacho wrote: > Tracker-extract is not as exposed as Firefox, because the file needs > being in the local filesystem for starters. The web world is well > known for figuratively throwing 3rd party media content to your face, > even in otherwise trusted websites. I think the concern here is that browsers allow websites to download files to your computer without any user interaction. Epiphany goes as far as to open them automatically. I've never previously considered that it's a security risk, simply because attacking an unsandboxed web engine seems like a much easier attack vector, but maybe we should think about changing this behavior. That said, we cannot stop running tracker on ~/Downloads because we want to show downloaded files in our core apps. Similarly, we're going to be processing the files with thumbnailers like the totem thumbnailer as well. Even if we sandbox tracker-extract, that does nothing to avoid bugs that exploit the thumbnailer, so we should really be looking at GStreamer-level mitigation anyway. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
review swap
Hi, I have this small Python package for review https://bugzilla.redhat.com/show_bug.cgi?id=1398369 I'm not sure about the latest Python packaging guidelines (python34 vs python3 on EL7/Fedora) concerning scripts, so the review will require a couple of iterations. Marcin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: review swap
hi Marcin, take! have time for this https://bugzilla.redhat.com/show_bug.cgi?id=1244657 ? thanks in advance regards .g Il 24/11/2016 16:09, Marcin Dulak ha scritto: Hi, I have this small Python package for review https://bugzilla.redhat.com/show_bug.cgi?id=1398369 I'm not sure about the latest Python packaging guidelines (python34 vs python3 on EL7/Fedora) concerning scripts, so the review will require a couple of iterations. Marcin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: HEADS UP: eigen-3.3.0 update
On 24.11.2016 12:56, Dominik 'Rathann' Mierzejewski wrote: On Wednesday, 23 November 2016 at 22:45, Sandro Mani wrote: Hi eigen-3.3.0 was released a a couple of weeks ago, and I've investigated the consequences of updating in rawhide in this [1] COPR repo. The detailed analysis is below, the summary is: - five dependent packages fail to build due to the eigen3 update: avogadro, ceres-solver, kalzium, shogun and tapkee - of these, ceres-solver, shogun and tapkee can be fixed by upgrading to newer versions (first two) or backporting upstream fixes (tapkee) - (The shogun update needs viennacl which is stalled in review [2]) - avogadro relies on the eigen-2.x compatibility which was removed in eigen-3.3, and there is not progress upstream so far in resolving the issue. Why not unretire eigen2 and build avogadro against that? Or does it use eigen3 features as well? AFAICS avogadro can still be built against eigen2, so sure, that would also be a plan. Not sure if reviving the package is better than bundling though, since eigen2 is completely unsupported upstream and its use not recommended [1]. I wouldn't want people starting to use the eigen2 package if it becomes available in the repos again. [1] http://eigen.tuxfamily.org/index.php?title=Eigen2 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Rawhide-20161124.n.0 compose check report
Missing expected images: Workstation live i386 Kde live x86_64 Kde raw-xz armhfp Workstation live x86_64 Kde live i386 Failed openQA tests: 7/79 (x86_64), 1/2 (arm) New failures (same test did not fail in Rawhide-20161123.n.1): ID: 49673 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/49673 ID: 49721 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/49721 ID: 49738 Test: x86_64 universal install_rescue_encrypted URL: https://openqa.fedoraproject.org/tests/49738 Old failures (same test failed in Rawhide-20161123.n.1): ID: 49660 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/49660 ID: 49686 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/49686 ID: 49703 Test: x86_64 universal install_ext3 URL: https://openqa.fedoraproject.org/tests/49703 ID: 49707 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/49707 ID: 49724 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/49724 Passed openQA tests: 69/79 (x86_64), 15/15 (i386) New passes (same test did not pass in Rawhide-20161123.n.1): ID: 49654 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/49654 ID: 49655 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/49655 ID: 49656 Test: i386 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/49656 ID: 49657 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/49657 ID: 49658 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/49658 ID: 49659 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/49659 ID: 49662 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/49662 ID: 49663 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/49663 ID: 49664 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/49664 ID: 49665 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/49665 ID: 49666 Test: x86_64 Server-dvd-iso base_selinux URL: https://openqa.fedoraproject.org/tests/49666 ID: 49667 Test: x86_64 Server-dvd-iso base_services_start URL: https://openqa.fedoraproject.org/tests/49667 ID: 49668 Test: x86_64 Server-dvd-iso base_service_manipulation URL: https://openqa.fedoraproject.org/tests/49668 ID: 49669 Test: x86_64 Server-dvd-iso base_update_cli URL: https://openqa.fedoraproject.org/tests/49669 ID: 49671 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/49671 ID: 49672 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/49672 ID: 49675 Test: x86_64 Server-dvd-iso server_cockpit_default URL: https://openqa.fedoraproject.org/tests/49675 ID: 49676 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/49676 ID: 49679 Test: x86_64 Server-dvd-iso server_role_deploy_database_server URL: https://openqa.fedoraproject.org/tests/49679 ID: 49680 Test: x86_64 Server-dvd-iso server_database_client URL: https://openqa.fedoraproject.org/tests/49680 ID: 49681 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/49681 ID: 49682 Test: x86_64 Server-dvd-iso server_firewall_default URL: https://openqa.fedoraproject.org/tests/49682 ID: 49683 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/49683 ID: 49684 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/49684 ID: 49685 Test: x86_64 universal install_package_set_minimal URL: https://openqa.fedoraproject.org/tests/49685 ID: 49688 Test: x86_64 universal install_repository_http_variation URL: https://openqa.fedoraproject.org/tests/49688 ID: 49689 Test: x86_64 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/49689 ID: 49690 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/49690 ID: 49691 Test: x86_64 universal install_delete_pata URL: https://openqa.fedoraproject.org/tests/49691 ID: 49692 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/49692 ID: 49693 Test: x86_64 universal install_kickstart_user_creation URL: https://openqa.fedoraproject.org/tests/49693 ID: 49694 Test: x86_64 universal install_scsi
Re: F24 GStreamer zero day
On Nov 24, 2016 2:03 AM, "Carlos Garnacho" wrote: > > Hi, > > > On Wed, Nov 23, 2016 at 5:03 PM, Carlos Garnacho > > > I'm objecting to whatever piece of software opens thoroughly untrusted > > files out of ~/Downloads and parses them. If that's not "Tracker", > > then I apologize. > > > > > > Firefox is a big piece of code that loads untrusted stuff. It's > > written in a memory-unsafe language, and there's a big team working on > > fixing that. It's not sandboxed, and there's a project to fix that. > > And it's still a major attack vector, but at least it has a very > > serious security team. > > Sounds great, do they also get the blame for gstreamer bugs? I've got lots of fun so share ;). > > According to you Firefox is just as insecure, and I can tell that Firefox uses GStreamer to open untrusted content over the internet. Why downloading the file at all, you could be tricked into a webpage that auto-plays the infected content, it could even be an ad unbeknownst by the site, you got every bit as infected and Tracker wasn't involved, using the exact piece of sofware as attack vector that we're talking nowadays. Because Firefox doesn't allow all of the GStreamer content types. And Firefox has its own mp4 container parser written in Rust these days, I think. IOW they admit its a problem and they've made it better. > > And as for the projects themselves, Tracker is a fraction of Firefox in terms of code size, and tracker-extract inside Tracker is another fraction. That makes a whole lot difference between auditing or securing a *web engine* and a process that essentially iterates over files. Why is Firefox then any more credible? Must be the serious looks of their security team. If a distro didn't provide a browser by default, no one would notice. If a distro didn't index media metadata in Downloads by default, I suspect most users wouldn't even notice. > > > > > The fact that flatpak integration is being planned is great. I hope > > that flatpak has an exceedingly strict mode for applications like > > this. > > > > Tracker is just as exposed as Firefox because it (or some piece of it > > or whatever) parses stuff in Downloads. > > Tracker-extract is not as exposed as Firefox, because the file needs being in the local filesystem for starters. The web world is well known for figuratively throwing 3rd party media content to your face, even in otherwise trusted websites. > Then at *least* stop indexing Downloads by default. My point is that the default tracker configuration is wildly insecure and it could be improved quite easily. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F24 GStreamer zero day
- Original Message - > On 23 November 2016 at 14:03, Chris Murphy wrote: > > On Wed, Nov 23, 2016 at 10:36 AM, Adam Williamson > > wrote: > >> On Wed, 2016-11-23 at 10:33 -0800, Andrew Lutomirski wrote: > >>> On Nov 23, 2016 10:12 AM, "Michael Catanzaro" > >>> wrote: > >>> > > >>> > On Wed, 2016-11-23 at 16:36 +0100, Hans de Goede wrote: > >>> > > I don't think that is entirely true. I've recently been trying > >>> > > to get gnome3 to run on under-powered machines like cheap ARM > >>> > > tablets, and I can do "dnf remove tracker" more or less just > >>> > > fine, I loose totem due to some weird dependency chain, and I > >>> > > think also gnome-documents which I guess is an issue for some > >>> > > use-cases, but most of gnome will stay and work just fine. > >>> > > >>> > Besides those, also gnome-photos and gnome-music (which aren't > >>> > installed by default currently, but will eventually be). And indexed > >>> > search is really very important for nautilus. > >>> > >>> That's indexed search by *name*, right? I can't imagine *any* reason > >>> that > >>> running a codec in the indexer is needed for nautilus. > >> > >> "I want to find all the files I have that are songs by Justin Bieber, > >> so I can shoot them into outer space". > > > > Pretty sure such metadata is a function of the container format, e.g. > > mp4, m4a, rather than the codec used for encoding the music or video > > itself. > > It might be but because most people tie those two things together when > they are writing code.. they get bundled together. This is why codecs > have been such a rich target in Windows (and in some ways Mac) malware > over the years. You get two channels to build an exploit for free :). They're not bundled together. Especially seeing as the popular filetypes have codecs depending on patents whereas the container formats don't. We've been able to tell you how long your DivX or MPEG-4 files were, out-of-the-box, on Fedora, for years. We just can't play them out-of-the-box. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F24 GStreamer zero day
On Thu, Nov 24, 2016 at 11:02:19AM -, Carlos Garnacho wrote: > > Question which directories does tracker actually scan / monitor by > > default ? > XDG folders recursively, $HOME non-recursively. This is all > configurable in the privacy pane in the control-center fwiw. It doesn't seem to be -- I see Screen Lock, Location Services, Usage & History, Purge Trash, and Problem Reporting. I have to to install tracker-preferences to get a GUI for these settings, as far as I can see. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F24 GStreamer zero day
On Thu, 2016-11-24 at 12:09 -0500, Matthew Miller wrote: > On Thu, Nov 24, 2016 at 11:02:19AM -, Carlos Garnacho wrote: > > > Question which directories does tracker actually scan / monitor > > > by default ? > > > > XDG folders recursively, $HOME non-recursively. This is all > > configurable in the privacy pane in the control-center fwiw. > > It doesn't seem to be -- I see Screen Lock, Location Services, Usage > & History, Purge Trash, and Problem Reporting. I have to to install > tracker-preferences to get a GUI for these settings, as far as I can > see. It's configurable in the Search panel of the control center. (the gear icon in the bottom right) -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F24 GStreamer zero day
On Thu, Nov 24, 2016 at 07:05:38PM +0100, Mathieu Bridon wrote: > > > XDG folders recursively, $HOME non-recursively. This is all > > > configurable in the privacy pane in the control-center fwiw. > > It doesn't seem to be -- I see Screen Lock, Location Services, Usage > > & History, Purge Trash, and Problem Reporting. I have to to install > > tracker-preferences to get a GUI for these settings, as far as I can > > see. > It's configurable in the Search panel of the control center. > (the gear icon in the bottom right) Cool, thanks. That's probably more obvious than Privacy anyway. :) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Self Introduction: Fabio Valentini (decathorpe)
Here goes my introduction as a new (or aspiring) package maintainer for fedora. I have been using fedora as my daily driver OS for some years now (I think starting with f18 or f19). Also, I have been learning to build RPM packages for some time, too - some of you may be familiar with my elementary-stable/nightly and/or syncthing COPR repositories. And now I decided the time has come to begin submitting my elementary packages for review :) I am already in frequent contact with the upstream developers, who have - most of the time - been really helpful with fixing issues of portability and compatibility with fedora. My first review request can be found at [1]. To give some more background about myself: I am currently studying Computer Science and Chemistry at the University of Innsbruck / Austria (and yes, my native language is German). I have some experience writing C and Java code (mostly because of University courses) and have taught myself some Python, too. I am also currently undergoing the "functional programming treatment" (with OCaml). Probably the project that I am most proud of (aside from packaging / my COPR repositories) is a simple, configurable and modular build tool for automatically constructing RPM packages (written in python3): kentauros (you can find it on github) - but it is far from finished yet (although I am already heavily using it for stable and automagic nightly builds for my COPR repositories). I am really looking forward to contributing to fedora and to collaborating with the fedora community. Fabio [1] https://bugzilla.redhat.com/show_bug.cgi?id=1398433 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F24 GStreamer zero day
On Thu, Nov 24, 2016 at 09:03:24AM -0600, Michael Catanzaro wrote: > On Thu, 2016-11-24 at 10:02 +, Carlos Garnacho wrote: > > Tracker-extract is not as exposed as Firefox, because the file needs > > being in the local filesystem for starters. The web world is well > > known for figuratively throwing 3rd party media content to your face, > > even in otherwise trusted websites. > > I think the concern here is that browsers allow websites to download > files to your computer without any user interaction. Epiphany goes as > far as to open them automatically. I've never previously considered > that it's a security risk, […] What does that mean, exactly? Does it pass the downloaded file to xdg-open or equivalent? Just because you clicked on a link on some website, no matter the file type and association involved? Seriously? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: upcoming build and release developer flag day December 12 2016
Peter Robinson wrote: > Well the koji web interface itself doesn't use authentication anymore, > from a fedpkg PoV there's a lot of complexity with http(s) because it > could be proxied or NATed (worst is CG-NAT) so the same connection > from the same laptop might not even come via the same IP. Basically > what you're describing is exactly what kerberos solves, tokens to > authenticate various different connections. My point is, just use SSH instead of HTTP(S) as the transport. You could even tunnel HTTP over an SSH tunnel after you let SSH authenticate the other end, if you really need an HTTP API. (Not much point in using HTTPS over the already encrypted SSH.) > A lot of companies and data security standards explicitly disallow ssh > keys because of the fact it's client side pass phrases with no way to > enforce a policy so there's no way to tell even if the key has a > passphrase. And that is what I like about SSH. :-) I decide the level of security I actually need for my key, not somebody else. And we already trust SSH authentication for access to dist-git, so I don't see why it would not be good enough for Koji as well. > Personally I'd like to see eventually the move to kerberos to replace ssh- > keys as it's easier to enforce a minimum policy and manage. Kinit just takes a password, automating it to pick the password from any password store or even a plaintext file and then run automatically on startup and automatically renew expired tickets is not that hard. It will just be a minor annoyance until one of us writes the automation tool, and do nothing to enforce any kind of policy on us. The infrastructure really needs to work for us, not against us. As for the other reply: Stephen John Smoogen wrote: > Off-list: Not quite. :-) > [snip] > Does that make sense? No. See my reply to Peter Robinson above. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F24 GStreamer zero day
Florian Weimer wrote: > What about the larger picture? Can tracker be made optional again for > the GNOME desktop? Tracker is just a red herring. GStreamer flaws can be exploited directly in any browser that actually uses GStreamer, e.g., all the WebKit (WebKitGtk, QtWebKit, but not Blink/Chromium) ones, KHTML, etc. For Chromium/Chrome, you only have to go through the download autosaving misfeature and Tracker because Chromium/Chrome does not use GStreamer. These flaws are much more critical than people seem to think! Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F24 GStreamer zero day
Michael Stahl wrote: > looks like both core Gnome apps and Qt5/KDE have apparently managed to > grow dependencies on the toxic codecs. The thing is, they both need only one or two of the offending codecs (not necessarily the same ones). In the Plasma case, the dependency is kwin → qt5-qtmultimedia → libgstphotography-1.0.so.0. If that were moved to a dedicated subpackage, we would avoid dragging in the whole set. But still, GStreamer upstream's approach of "oh, those plugins are bad, don't use them, we don't care about their security" does not work at all. People WILL end up installing them no matter what we do (even if we don't package them at all, they will surely spring up in Copr/OBS/wherever), and an attack can be as simple as visiting a web page. Upstream really needs to audit ALL plugins for security. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: HEADS UP: eigen-3.3.0 update
Sandro Mani wrote: > AFAICS avogadro can still be built against eigen2, so sure, that would > also be a plan. Not sure if reviving the package is better than bundling > though, since eigen2 is completely unsupported upstream and its use not > recommended [1]. I wouldn't want people starting to use the eigen2 > package if it becomes available in the repos again. Another alternative would be to make an eigen32 compatibility package with 3.2. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: HEADS UP: eigen-3.3.0 update
Sandro Mani wrote: > - avogadro relies on the eigen-2.x compatibility which was removed in > eigen-3.3, and there is not progress upstream so far in resolving the > issue. https://github.com/cryos/avogadro/issues/842 Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: HEADS UP: eigen-3.3.0 update
Sandro Mani wrote: > - avogadro relies on the eigen-2.x compatibility which was removed in > eigen-3.3, and there is not progress upstream so far in resolving the > issue. https://github.com/cryos/avogadro/issues/842 Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: HEADS UP: eigen-3.3.0 update
Sandro Mani wrote: > - avogadro relies on the eigen-2.x compatibility which was removed in > eigen-3.3, and there is not progress upstream so far in resolving the > issue. https://github.com/cryos/avogadro/issues/842 Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
