Re: Proposal to reduce anti-bundling requirements
On 15.09.2015 15:58, Simo Sorce wrote: > On Tue, 2015-09-15 at 09:41 -0400, Carlos O'Donell wrote: >> On 09/14/2015 08:29 AM, Florian Weimer wrote: >>> I think the real issue here is the ELF model with backwards/forwards >>> linking and symbol interposition. Ideally, we should load each DSO >>> exactly once, resolve object symbols only against explicit DT_NEEDED >>> dependencies (not indirect dependencies), and make most symbols >>> non-interposable by default. At least this is my gut feeling. This is >>> a very difficult problem, especially at distribution scale. >> >> I'm not sure how difficult this would be because I'm not sure how many >> symbols rely upon indirect dependencies. I think it would be a worthwhile >> cleanup to turn on something like you suggest, and attempt to bootstrap >> the OS using Fedora Bootstrap [1]. > > Symbol interposition is used a lot for very useful features, blocking > interposition would break a lot of stuff. really? i've always thought that it was only useful for libc symbols, but maybe that's because i don't work on base OS stuff. by my naive count we have 341k exported symbols in LibreOffice, and of those, 4 of them used to be interposeable in a practically useful way (to override the custom memory allocator for valgrind), but even those are useless nowadays since the G_SLICE environment variable disables the custom allocator. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Checking the ABI of packages submitted to the updates-testing Fedora repository
On 08.06.2015 12:37, Petr Pisar wrote: > On 2015-06-05, Dodji Seketeli wrote: >> The nature of programs written in these dynamic languages makes it quite >> hard to compare types used in the API entry points of a library > > Pedantic note: There is difference between dynamic vs. static languages > and dynamically vs. statically typed languages. While dynamic languages > usually are dynamically typed, it does not imply it. while we are being pedantic, we would be remiss not to mention that there is no such thing as "dynamically typed", given that types are a *syntactic* property. "A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute." - Pierce, Benjamin C. (2002). Types and Programming Languages. MIT Press. ISBN 978-0-262-16209-8. for further discussion of the topic including an explanation of how the term "dynamic language" actually goes back to the Visigoths, i refer to: http://lambda-the-ultimate.org/node/1562#comment-18623 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Maybe it's time to get rid of tcpwrappers/tcpd?
On 06/06/14 00:25, David Sommerseth wrote: > On 20/03/14 20:05, Lennart Poettering wrote: >> On Thu, 20.03.14 12:20, Stephen John Smoogen (smo...@gmail.com) wrote: >> I doubt there are many people even using them anymore, firewalls are more comprehensive and a lot more powerful, and while every admin knows firewalls, I figure only very few know tcpd/tcpwrap, and even fewer ever actively make use of them... >>> Actually they are used quite a bit in various service worlds. Mainly for >>> ssh and email for dealing with scanners. [DenyHosts is a boon in this >>> area.] The reason for using a secondary tool is that depth of >>> security. >> >> Well, all mails servers as well as sshd have much better ways to do >> such filtering. sshd has "Match", Postfix for example has >> "smtpd_client_restrictions=", and so on. >> >> Again, I have no doubt that some people still use tcpwrappers. But I'd >> argue that is clearly the excpetion, not the rule, and they'd better use >> something different, and that we should be creating an excellent distro, >> instead of a one that features horrible software... >> >>> Over the years I have found that there are multiple of attacks which will >>> nullify one layer of protection at one point or another. Having a second >>> level or third level of protection is a boon when this happens. >> >> Well, it certainly makes sense to combine a firewall with let's say >> selinux with maybe postfix/ssh acls. Then you already have three layers >> of protection, of very good protection. But of all possible options >> tcpwrap is the absolute worst choice. And we should be able to deprecate >> and remove stuff from our core OS if we think it is crap. >> >> I mean, there are two sides of the medal: sure multiple layers of >> protection might be a good thing, but you also make things a lot more >> complex with each one, and you involve more possibly exploitable code -- >> and tcpwrap is simply bad code, that's a fact. So you have to balance >> things out: is something a layer that is worth the trouble? Or does >> having it around make things worse? I am of the opinion that tcpwrap >> indeed does make things worse. > > I happen to share Stephens concerns. I think tcpwrappers is a good > additional security layer. And I honestly don't buy the idea that code > which is 11 years old is crap by default. If it has gone 11 years, > being widely used by several services (including high-profile services > such as SSH), that tells me something about the quality of the > *performing* code. New code is better just because it's new. you are *clearly* not up-to-date with regard to currently on-going flame-wars: "heads up: tcpwrappers support going away" Damien Miller djm at mindrot.org Tue Apr 22 17:33:59 EST 2014 http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-April/032497.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The right way to git clone a subversion repo...
On 08/01/14 14:27, Darryl L. Pierce wrote: > The problem is that it's been HOURS and Git hasn't finished cloning the > tree. > It's the third step which is taking forever to complete. I left it to > run overnight (10 hours) and it never finished. I paused it, came to > work, resumed it and it's still going. > > Should this process really take this long? of course it shouldn't, considering the state of the SCM art. but this is SVN, so that is entirely expected. > Or is there a faster, more > efficient way to do this? I know that part of what'll make it take so > long is the amount of history that has to be extracted from Subversion. > But is that many hours normal or did I do something wrong? perhaps you can prod upstream to migrate to something better. btw if the clone is interrupted you can just continue with "git svn fetch", so at least you don't have to start from scratch. oh, and consider yourself lucky that the only SVN repo _only_ has 13k commits and isn't just part of a single giant 100-project repo :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: BerkeleyDB 6 symbol versioning and associated problems
On 07/05/14 15:39, Joe Orton wrote: > On Wed, May 07, 2014 at 03:19:42PM +0200, Jan Staněk wrote: >> One of the planned parts of the F21 System Wide Change: BerkeleyDB 6 [1] >> is the introduction of downstream symbol versioning of both versions of >> the libraries (libdb with v6 and libdb5 with v5). This part is planned >> in order to not introduce bugs similar to [2]. However, if we introduce >> downstream versioning (as upstream is generally unresponsive), then we >> face the problem similar to [3]. > > If we keep libdb5 (forever?) then the [3] problem is less of an issue, > IMO. Given that portably linking against libdb has historically been a > major headache I'd be surprised if there are any binary third-party apps > which even try doing this, to be honest. for a data point, see this OOo commit from 2007 which equips the (bundled, of course) libdb*.so with a custom version script just to avoid conflicts and resulting crashes: http://cgit.freedesktop.org/libreoffice/core/commit/?id=cd83aeb5fdde8184aa8226a9334546c413c1b318 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: crypto consolidation status
On 03/12/13 19:58, Tomas Mraz wrote: > On Út, 2013-12-03 at 18:46 +0100, Jan Včelák wrote: >> Hello list. >> >> What is the current status of Crypto Consolidation in Fedora? Is it still >> current and is the page up to date [1]? > > The page is mostly up to date. interesting page... under "Packages to NSS-enable" there is: 12. OpenOffice .. so yes "mostly" :) LibreOffice 4.2 will remove the last internal dependency on OpenSSL and uses NSS throughout; for rawhide i have just removed the "BuildRequires: openssl-devel". upstream there are still some dependencies on OpenSSL in bundled externals (python3, postgresql, neon) that we would actually like to get rid of (because OpenSSL must be bundled and linked statically due to its ever-changing ABI etc.) but haven't yet; this does not affect Fedora LO packages though. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fwd: [Libjpeg-turbo-users] jpeg-9, API/ABI compatibility, and the future role of this project
On 15/01/13 20:04, Xose Vazquez Perez wrote: > On 01/15/2013 01:01 PM, Adam Tkac wrote: > >> Another interesting thread is >> http://sourceforge.net/mailarchive/message.php?msg_id=30352453 >> >> We are currently discussing drop of the >> https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI feature >> because >> SmartScale encoding (only reason of the jpeg7 and jpeg 8 ABI bumps) was >> rejected >> by ISO and actually doesn't bring any benefit over widely used png/webp >> codecs. >> >> So Fedora will probably stick with old jpeg6 API/ABI unless IJG maintainer >> reveals some new facts about SmartScale. All facts are currently against >> SmartScale (image quality/size, compression/decompression speed). > > Upstream Tracker shows 0% of binary compatibility with previous > releases: http://upstream-tracker.org/versions/libjpeg.html > > I hope other distributions don't use that release. FWIW i'm afraid i've had to build jpeg8 from source already to get a certain binary [1] built on Ubuntu to run on Fedora 17... [1] actually a git repo full of binaries: https://wiki.documentfoundation.org/Bibisect -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [Libjpeg-turbo-users] jpeg-9, API/ABI compatibility, and the future role of this project
On 16/01/13 16:55, Adam Tkac wrote: > On Wed, Jan 16, 2013 at 01:02:57PM +0100, Michael Stahl wrote: >> On 15/01/13 20:04, Xose Vazquez Perez wrote: >>> I hope other distributions don't use that release. >> >> FWIW i'm afraid i've had to build jpeg8 from source already to get a >> certain binary [1] built on Ubuntu to run on Fedora 17... >> >> [1] actually a git repo full of binaries: >> https://wiki.documentfoundation.org/Bibisect > > I read the link and it seems libjpeg62 is sufficient (i.e. jpeg6 ABI) for > bibisect. So > you should not need jpeg8 ABI. read more carefully then: the git repo contains binaries built against different Ubuntu baseline versions, the older of which have jpeg6 and the newer jpeg8. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [Libjpeg-turbo-users] jpeg-9, API/ABI compatibility, and the future role of this project
On 16/01/13 21:40, Tom Lane wrote: > Michael Stahl writes: >> read more carefully then: the git repo contains binaries built against >> different Ubuntu baseline versions, the older of which have jpeg6 and >> the newer jpeg8. > > [ shrug... ] So we'd be incompatible with some of them no matter what. > But the bigger point is that we can't let Ubuntu make decisions for us > about which versions of which packages Fedora is going to ship. oh certainly, i just wanted to point out that hoping that "other distributions don't use that release" is futile -- it's already too late :( (also i forgot to mention that my problem could easily be avoided by using a --without-system-jpeg option when building those binaries; the guy who built them already has my complaint on file :). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
On 04/02/13 01:37, Peter Boy wrote: > > By the way: As I learnt on Linux Day last year, LibreOffice still > depends on OpenOffice and is in the process to rebase their code to > OpenOffice 3.4 (or something alike). So I'm wondering about different > set of features. how exactly does LibreOffice "depend" on OpenOffice, and what do you mean by "OpenOffice" in this context? LibreOffice has merged in OpenOffice.org code for as long as that was still developed, up to the DEV300_m106 milestone that was current at the time of the death of OpenOffice.org in April 2011. currently LibreOffice is being "re-based" on the Apache OpenOffice 3.4 release, since Oracle did not grant TDF and the LibreOffice project a different license to the OpenOffice.org code (it seems that favour is not granted to everyone); one of the main goals of this is to be able to offer the LibreOffice code to the main corporate backer of the Apache OpenOffice fork under a license that they find acceptable (MPL), in the hope that they will stop wasting everybody's time with the current duplication of efforts and stupid politics. for more info see: https://wiki.documentfoundation.org/Development/Re-Basing regrads, michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
On 04/02/13 13:59, Martin Sourada wrote: > Also, going by your reasoning there would be no point in having > Calligra either... Furthermore, technically LO is the fork ;-) technically, both Apache OpenOffice and LibreOffice are forks, since neither of them: a) are under the OpenOffice.org governance scheme b) are developed under the processes that OpenOffice.org used c) require a copyright assignment to Sun/Oracle to contribute d) license the code under LGPLv3 as OpenOffice.org always was [this is technically still true for LibreOffice but will change] e) are developed by the Sun/Oracle staff that have always done the majority of the programming on OpenOffice.org in its time f) run on the infrastructure in Sun/Oracle's Hamburg lab -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Static Analysis: some UI ideas
On 05/02/13 17:57, David Malcolm wrote: > On Tue, 2013-02-05 at 13:02 +0100, Kamil Dudka wrote: >> On Monday 04 February 2013 22:37:45 David Malcolm wrote: >>> Content-addressed storage: they're named by SHA-1 sum of their contents, >>> similar to how git does it, so if the bulk of the files don't change, >>> they have the same SHA-1 sum and are only stored once. See e.g.: >>> http://fedorapeople.org/~dmalcolm/static-analysis/2013-01-30/python-ethtool >>> -0.7-4.fc19.src.rpm/static-analysis/sources/ I probably should gzip them as >>> well. >> >> This can indeed save some space. I really like the idea. Maybe using a >> true >> git store would give you additional reduction of space requirements thanks >> to >> using the delta compression. > > Interesting. I had thought that git purely stored compressed files and > eschewed the idea of deltas, but it does indeed store deltas sometimes: > http://git-scm.com/book/ch9-4.html git makes for surprisingly good storage (it's just a pity about the UI); for example (ab)use see http://nabble.documentfoundation.org/What-is-bibisect-And-what-is-it-doing-in-my-office-td3572953.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Abrt (was Re: Most buggy packages)
On 20/02/13 09:40, Jiri Moskovcak wrote: > One thing we're struggling with now is the normalization of stacktraces > which means deciding which functions are important and which are not. > e.g. for kernel there are stacktraces with a lot of warn_* functions and > only a few functions are different and our logic detects this as a > duplicate because the stacktraces are very similar. We're dealing with > this problem, but it's very slow process because to make such decision > you need to know the specific program and we would appreciate any help > with this matter. that reminds me; we have had a similar problem with ABRT and LibreOffice, if an in-process JVM is loaded. see for example: https://bugzilla.redhat.com/show_bug.cgi?id=731614#c9 when the in-process JVM is active and some SEGV occurs, the JVM has its own handler to handle it (even though usually it's a crash in LO's C++ code) and that leads to ~10 identical JVM stack frames on the top, regardless of the actual cause of the crash, and those are of course easily wrongly detected as duplicates. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Wayland and Fedora
On 20/03/13 13:52, Neal Becker wrote: > I'm also curious about how wayland might work with kde. this page indicates that KDE developers intend to turn KWin into a Wayland compositor/server, similar to what Matthias just proposed/announced for gnome-shell: http://community.kde.org/KWin/Wayland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the offline updates user experience
On 17.09.2014 13:58, Miroslav Suchý wrote: > On 09/17/2014 11:54 AM, Bastien Nocera wrote: >> All those OSes require reboots when updating the OS. > > Define OS. > > Firefox is definitely not OS. While systemd is OS. > I am fine with reboot after systemd upgrade, but not after upgrading Firefox. the important point in that case is not reboot after upgrading Firefox but *before* upgrading Firefox, which means that at the time of the upgrade no Firefox will be running and potentially crashing because one of the 100s of DSOs it loads on-demand has changed in an incompatible way. there used to be quite a few ABRT crashes reported against desktop applications with impossible looking stack traces (although with the automatic micro-reports it's less of a problem nowadays as they are easier to ignore), and sometimes the reporter gives feedback that the application was running across a yum update... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rawhide report: 20141028 changes
On 28.10.2014 16:10, Adam Jackson wrote: > On Tue, 2014-10-28 at 10:57 +, Fedora Rawhide Report wrote: > >> [dragonegg] >> dragonegg-3.4-0.3.rc0.fc21.i686 requires libLLVM-3.4.so >> dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 > > This one's a joy. dragonegg is a gcc plugin that basically replaces the > middle and back ends; gcc's parser, llvm's optimizers, llvm's code > generators. There's a dragonegg 3.5.0 to match llvm 3.5.0, but since > gcc's plugin API is just as unstable as llvm's, it only supports through > gcc 4.8. > > But dragonegg is busted in F21 already, because (as above) it was built > against gcc 4.8 and F21 is gcc 4.9. Can we block or retire dragonegg? honestly i wonder what the use-case for dragonegg is anyway... the other way around (LLVM's user-friendly front-end and GCC's back-end generating faster code) would be more interesting... does it have actual real-world users? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora tcp_wrappers (missing) support for custom acl scripts, aclexec
On 09.01.2015 23:16, Pasi Kärkkäinen wrote: > Hello, > > I recently noticed Debian/Ubuntu has had support for "aclexec" in > tcp_wrappers via a custom patch since 2006, > so you can do this in /etc/hosts.allow or hosts.deny: > > sshd: ALL: aclexec /usr/local/bin/sshfilter.sh %a > > if sshfilter.sh returns true the access is allowed, if sshfilter.sh returns > false the access is denied. > Very handy for integrating DNS RBLs and other IP databases etc. > > What do people feel about that? I'd like to see support for aclexec included > in Fedora's tcp_wrappers package. seems a bit pointless to add this now considering this bit from the OpenSSH 6.7 release notes: http://lwn.net/Articles/615173/ * sshd(8): Support for tcpwrappers/libwrap has been removed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Eliminating automatic provides on private libs
[resent another time because the list automatically rejected my mail]
On 27/04/12 10:13, Panu Matilainen wrote:
[...]
> The short background is that for libraries which dont have a SONAME,
> rpmbuild fakes one based on the file name. The rationale for this has
> been that since the linker permits linking to libraries without sonames,
> rpm must permit this too. The downside is that for the 1% corner cases
> that need this, we end up polluting the provides namespace with
> thousands of unnecessary and unwanted names, names that have not been
> picked up with a global namespace in mind.
[...]
> So... about a third of the soname provides are faked by using library
> basename for its provide name, and almost all of them are for no good
> reason. The three general cases that something actually depends on are
> 1) libreoffice sub-packages depending on its internal libraries from
> libreoffice-core
while i'm still quite unfamiliar with RPM or the libreoffice.spec file,
i'm very familiar with LibreOffice upstream; generally with the
exception of the -ure sub-package there are no stable ABIs provided by
the various libraries, so the sub-packages need to depend on the exact
same version of the core package anyway (and no code outside of the
libreoffice source package should have dependencies) which is probably
why the spec file contains this:
Requires: %{name}-core = %{epoch}:%{version}-%{release}
now the URE (UNO runtime environment) subpackage actually provides a
stable ABI and libraries with SONAMEs (in addition to some private
libraries without SONAME for dlopen), all installed in a sub-directory
of /usr/lib/libreoffice, but other than the other libreoffice
sub-packages, which again depend on it with exact version
Requires: %{name}-ure = %{epoch}:%{version}-%{release}
using repoquery i could find only 3 non-libreoffice packages with a
dependency on ure or its libraries in Fedora 16, all of which
LibreOffice extensions (actually 2 of the 3 are the same, once with the
old openoffice.org name), and depending only on the public libraries
with SONAME:
> repoquery --requires openoffice.org-voikko-0:3.1.2-5.fc16.x86_64
> openoffice.org-diafilter-0:1.7.0-6.fc15.x86_64
> libreoffice-voikko-0:3.2-4.fc16.x86_64
[...]
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Couldn't we enable 256 colors by default on TERM?
On 26/06/12 18:45, Miloslav Trmač wrote: > On Tue, Jun 26, 2012 at 3:24 AM, Matthew Garrett wrote: >> We discussed this in fesco today and had a couple of concerns. > > Another one is that connecting to systems that don't support xterm-256 > is not quite easy. In particular, there appears to be no way to > configure ~/.ssh/config so that "ssh oldhost" (and "ssh oldhost > arbitrarycommand") transparently changes the TERM value - one would > have to set up shell functions or something similar. An extension of > the ssh would be very nice - and failing that, an explicit recipe how > to override TERM correctly would be welcome as well. heh, that's exactly why this cruft ended up in my .bashrc :) > # "xterm" does not support color on solaris > # https://defect.opensolaris.org/bz/show_bug.cgi?id=1641 > case $(uname -s) in > SunOS) > case $TERM in > xterm) > TERM=xtermc > ;; > esac > ;; > # but only Solaris knows "xtermc" > *) > case $TERM in > xtermc) > TERM=xterm > ;; > esac > ;; > esac and that is just to get any colors at all... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox not working anymore over ssh?
On 29.03.2016 19:22, Tim Landscheidt wrote: > Michael Catanzaro wrote: > >>> Yes. This makes it work. Thanks a lot. > >> Then it was probably broken by this update: > >> https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253 > > The "LIBGL_DRI3_DISABLE=1" workaround fixed it for me as > well (running Iceweasel on a remote Debian box from a local > Fedora box). Does that mean that there is an error in Fe- > dora, Firefox/Iceweasel, something else? Is there a bug > tracking this? looks like https://bugzilla.redhat.com/show_bug.cgi?id=1174257 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
On 15.06.2016 08:24, Florian Weimer wrote:
> On 06/15/2016 06:27 AM, Andrew Lutomirski wrote:
>> On Tue, Jun 14, 2016 at 9:07 PM, Florian Weimer wrote:
>>> On 06/15/2016 04:11 AM, Andrew Lutomirski wrote:
>>>
I *strongly* disagree here. The xdg-app folks seem to be doing a
pretty good job with their sandbox. The kernel attack surface is
reduced considerably, as is the attack surface against the user via
ptrace and filesystem access. If Wayland is available (which is
should be!) then so is the attack surface against X.
>>>
>>>
>>> What about the direct access to DRI device nodes? Why isn't this a problem
>>> that reduces the effectiveness of the sandbox considerably?
>>
>> It's certainly a meaningful attack surface. That being said, if it
>> works well, it should be about as dangerous as Chromium's render
>> sandbox, and the latter seems to work fairly well in practice. I'm
>> assuming that xdg-app grants access to render nodes, not to the legacy
>> node.
>
> I'm not sure what kind of sandboxing there is. I was just able to open
> ~/.ssh/id_rsa from a Flatpak application, and change ~/.bash_profile
> (both outside the sandbox, obviously).
>
> I couldn't find any relevant device nodes in the file system namespace.
currently Flatpak doesn't have sandboxing enabled by default, since
substantial parts of the implementation of interfaces that allow the
applications to access resources outside the sandbox in a secure way
("Portals") are missing.
the design of the sandbox is documented here:
https://github.com/flatpak/flatpak/wiki/Sandbox
article about a sandboxed application (which doesn't need Portals):
https://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxed-linux-desktop-app/
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: OpenSSL-1.1.0 COPR for Rawhide
On 22.07.2016 16:53, Simo Sorce wrote: > On Fri, 2016-07-22 at 16:48 +0200, Tomas Mraz wrote: >> >> 2. Add compat 1.0.2 package which would be used by 3rd party >> applications and also temporarily by applications that are not yet >> ported to the new API. However the current plan is to not provide >> -devel subpackage for 1.0.2 compat packages so if you needed to rebuild >> something on rawhide you would have to fix the build issues with the >> new openssl. >> > I am concerned about a compat package because there are a lot of > components lining to openssl often libraries or modules, from different > source RPMS. So we incur the risk of getting a binary to link with both > version via modules/library dependencies and that would cause issues > (probably crashes, or perhaps bad behavior) only at runtime due to > symbol aliasing between the two versions. urgh, yes, that's practically guaranteed to crash LibreOffice which could pull in openssl via neon, python-stmp, postgresql-libs, openldap, curl, librdf, any gnome-vfs backend, and probably other ways i'm not aware of. the only safe way to provide a compat openssl package is as a -devel package that only contains a static library :P -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 GStreamer zero day
On 23.11.2016 01:57, Michael Catanzaro wrote: > Hi, > > Is anybody working on fixing [1]? > > The exploit is a little impractical in that it only works if you have > not updated any F24 base packages except GStreamer, but we should still > fix it. I don't see any GStreamer updates in bodhi yet. on a related note, i notice that i have this package installed, which i haven't requested to be installed: >> rpm -qa | grep gstreamer1-plugins > gstreamer1-plugins-base-devel-1.8.3-1.fc24.x86_64 > gstreamer1-plugins-bad-free-1.8.3-1.fc24.x86_64 > gstreamer1-plugins-good-1.8.3-1.fc24.x86_64 > gstreamer1-plugins-base-1.8.3-1.fc24.x86_64 >> dnf -C info gstreamer1-plugins-bad-free > Last metadata expiration check: 0:57:12 ago on Wed Nov 23 10:44:37 2016. > Installed Packages > Name: gstreamer1-plugins-bad-free > Arch: x86_64 > Epoch : 0 > Version : 1.8.3 > Release : 1.fc24 > Size: 5.4 M > Repo: @System > From repo : updates > Summary : GStreamer streaming media framework "bad" plugins > URL : http://gstreamer.freedesktop.org/ > License : LGPLv2+ and LGPLv2 > Description : GStreamer is a streaming media framework, based on graphs of > : elements which operate on media data. > : > : This package contains plug-ins that aren't tested well enough, > or > : the code is not of good enough quality. so to their credit the upstream authors in this case are honest enough that their C code is full of holes and shouldn't be used by anybody; however: >> dnf remove gstreamer1-plugins-bad-free > Dependencies resolved. > > Package Arch Version Repository > Size > > Removing: > PackageKit-Qt5x86_64 0.9.5-6.fc24 @@commandline 330 > k > appstream x86_64 0.9.8-3.fc24 @updates 670 > k > appstream-qt x86_64 0.9.8-3.fc24 @updates 92 > k > breeze-cursor-theme noarch 5.7.5-1.fc24 @updates 11 > M > cheesex86_64 2:3.20.2-1.fc24 @@commandline 406 > k > cln x86_64 1.3.4-4.fc24 @@commandline 1.5 > M > empathy x86_64 3.12.12-2.fc24@updates 15 > M > f23-backgrounds-kde noarch 23.1.0-2.fc24 @@commandline 211 > f23-kde-theme noarch 23.0-6.fc24 @@commandline 4.4 > M > f24-backgrounds-kde noarch 24.1.2-1.fc24 @@commandline 211 > f24-kde-theme noarch 24.5-1.fc24 @@commandline 2.4 > M > f24-kde-theme-corex86_64 5.7.5-2.fc24 @updates 169 > k > farstream02 x86_64 0.2.7-3.fc24 @@commandline 695 > k > gnome-dvb-daemon x86_64 0.2.91-0.2.20160917git2d32148.fc24 > @updates 2.1 > M > gstreamer1-plugins-bad-free x86_64 1.8.3-1.fc24 @updates 5.4 > M > gstreamer1-rtsp-serverx86_64 1.8.3-1.fc24 @updates 361 > k > hplip-gui x86_64 3.16.10-1.fc24@updates 2.1 > M > kactivitymanagerd x86_64 5.7.5-1.fc24 @updates 682 > k > kde-cli-tools x86_64 5.7.5-1.fc24 @updates 3.4 > M > kde-settings-plasma noarch 24-7.fc24 @updates 3.4 > k > kdecoration x86_64 5.7.5-1.fc24 @updates 185 > k > kf5-bluez-qt x86_64 5.27.0-1.fc24 @updates 700 > k > kf5-frameworkintegration x86_64 5.27.0-1.fc24 @updates 1.6 > M > kf5-frameworkintegration-libs x86_64 5.27.0-1.fc24 @updates 66 > k > kf5-kactivities-stats x86_64 5.27.0-1.fc24 @updates 290 > k > kf5-kdnssdx86_64 5.27.0-1.fc24 @updates 247 > k > kf5-kdoctools x86_64 5.27.0-1.fc24 @updates 2.2 > M > kf5-kemoticonsx86_64 5.27.0-1.fc24 @updates 2.2 > M > kf5-kholidays x86_64 16.08.2-1.fc24@updates 708 > k > kf5-kjsembed x86_64 5.27.0-1.fc24 @updates 1.7 > M > kf5-kpeople x86_64 5.27.0-1.fc24 @updates 465 > k > kf5-kwayland x86_64 5.27.0-1.fc24 @updates 1.3 > M > kf5-kxmlrpcclient x86_64 5.27.0-1.fc24 @updates 123 > k > kf5-networkmanager-qt x86_64 5.27.0-1.fc24 @updates 1.3 > M > khotkeys x86_64 5.7.5-1.fc24 @updates 2.3 > M > kio-extrasx86_64 16.08.2-1.fc
Re: Nautilus usability
On 11/28/2016 07:53 AM, Samuel Sieb wrote: > On 11/27/2016 10:40 PM, drago01 wrote: >> On Monday, November 28, 2016, Py mailto:p...@luyten.fr>> >> wrote: >> >An SSD drive might not have this problem, but a spinning disk >> >definitely >> >will. You should never try running multiple copies on the same disk if >> > >> >you want it to finish in a reasonable time. With one copy, you can do >> >long contiguous reads and writes, but if you have multiple copies >> >happening, the read and write head will be bouncing all over the disk. >> >> So ideally this is the file manager job to queue copy operations. >> This allows to do right even when the user is wrong, or wants to >> launch big copy before coffee. >> >> >> No. The kernel (io scheduler) is supposed to order requests to avoid >> this scenario. Also sequential reads / writes only happen for large >> files if there is no fragmentation. >> > How could the kernel ever schedule this nicely? Is it going to hold up > one process until the other one is finished? one thing the kernel knows reasonably well but user-space has to work out with some effort is which of the multiple copy operations the user has started are actually working on completely independent storage devices, in which case there is no penalty to doing them in parallel. is there an implementation of an heuristic to determine that from user-space? i'm quite sure it's more complicated than it appears at first glance, what with DM, MD, eCryptFS, FUSE, iSCSI, NFS etc. complicating things, not to mention you could be running in a VM where you have no idea where your "sda" and "sdb" actually are. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Get LLVM's libc++abi into Fedora, BZ1332306
On 15.02.2017 09:48, E.N. virgo wrote: >> I'm not sure if I follow. Supporting multiple C++ ABIs would make >> things more complicated for developers because they now have to figure >> out which ABI their project needs and if all the libraries they want to > > >> use are available with the right ABI. > > From the example in BZ1415512, all libraries are standard, the sources remain > the same regardless the compiler to be used. Alas, clang++ now needs to link > against the GCC ABI to successfully compile. what actual problem is caused by that? > There are some cases when one needs to try different tools, for instance to > take advantage of the LLVM's instrumentation tools which IMHO constitute a > plus, not a pain. which clang instrumentation tool requires libc++abi? all the sanitizers i tried work just fine with libstdc++. last i checked, libc++ didn't even have an equivalent of _GLIBCXX_DEBUG, which is a pretty severe limitation and makes it useless for me. >> I really don't think we should move in this direction. > > Are there pointers elsewhere indicating the corner cases of introducing > another C++ ABI into Fedora? there are subtle corner cases breaking exception handling: https://whatofhow.wordpress.com/2016/03/01/libclibcabi-on-linux/ but hey, some people think that spending many hours debugging that sort of thing is fun, so taking that as an argument against packaging libc++abi would clearly go against the C++ philosophy. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Understanding the Fedora Modularity initiative (video + slides)
On 24.03.2017 10:35, nicolas.mail...@laposte.net wrote: > Hi, > > IPS is a tweak on rpm. I suspect a mostly overengineered one, SUN had > massive ego problems and looked down on Linux systems. So they could > not just adopt rpm, they had to change it sufficiently to one up > Linux peasants (many of the original IP packages are based on an > import of Fedora rpm specs, with customizations like facets added > in) Why would Solaris switch to rpm, when they already had SysV packages at the time, which are pretty much equivalent in functionality? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Understanding the Fedora Modularity initiative (video + slides)
On 24.03.2017 13:34, nicolas.mail...@laposte.net wrote: >> Why would Solaris switch to rpm, when they already had SysV >> packages at the time, which are pretty much equivalent in >> functionality? > > Solaris at the time had degenerated into a barebones system, they > needed to find a way to import all the stuff packaged by Linux > distros of repackage thousands of components themselves. To give you > an idea how deep they had dug themselves before IPS, their main shell > was ksh, and they hadn't managed to migrate completely from ksh 88 to > 93 yet. > > Before they closed the doors again some of the IPS stuff was > available in public repos, complete with forks of Fedora specs (with > the original Fedora comments) and the added IPS enhancements such as > facets. so your argument is that Solaris created IPS because they wanted to steal a rpm of ksh93? the people doing the work claimed that the reason it wasn't done earlier is a long list of compatibility breakages in ksh93: http://markmail.org/message/m7jkcvb6tm5ffktb but why didn't they import all of those rpm specs as SysV packages? that ought to be much easier, given how much closer rpm is to SysV than to IPS... the latter doesn't even have pre/postinst scripts! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Graphical Applications as Flatpaks
On 16.07.2017 12:54, Richard W.M. Jones wrote: > On Fri, Jul 14, 2017 at 04:59:37PM +, Debarshi Ray wrote: >> On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote: >>> >>> If RPMs of the graphical application work fine now, what on earth is >>> the point of forcing packagers to make Flatpaks? Sandboxing isn't one >>> of them - as already explained, sandboxing is orthogonal to packaging. >> >> Huh? How would you get sandboxing without Flatpaks? Unless you are >> proposing a different sandboxing technology. > > Things like libvirt-sandbox have been around for a really long time > and don't require special packaging (in fact they work with any > arbitrary command). reading between the lines of the fine documentation, there is no mention of X11 or GUI applications, so i guess "arbitrary" is a bit of an exaggeration? http://sandbox.libvirt.org/quickstart/ http://sandbox.libvirt.org/faq/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Graphical Applications as Flatpaks
On 16.07.2017 14:10, Kevin Kofler wrote: > Debarshi Ray wrote: >> How about reliable online updates of running applications as a >> benefit? > > Upgrading RPM applications online just works. I do it all the time. The KDE > tools do not even implement offline updates (and IMHO that's a good thing). > The worst that can happen is that some recalcitrant applications (by far the > minority) need to be restarted after updating (or if you upgraded the whole > desktop, then your session may need to be restarted after updating). Until > you do that, the current session may be "hosed" to some extent, but > restarting will fix it. no, the worst case is this: https://www.happyassassin.net/2016/10/04/x-crash-during-fedora-update-when-system-has-hybrid-graphics-and-systemd-udev-is-in-update/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Graphical Applications as Flatpaks
On 17.07.2017 19:26, Richard W.M. Jones wrote: > On Mon, Jul 17, 2017 at 12:03:13PM +0200, Michael Stahl wrote: >> On 16.07.2017 12:54, Richard W.M. Jones wrote: >>> On Fri, Jul 14, 2017 at 04:59:37PM +, Debarshi Ray wrote: >>>> On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote: >>>>> >>>>> If RPMs of the graphical application work fine now, what on earth is >>>>> the point of forcing packagers to make Flatpaks? Sandboxing isn't one >>>>> of them - as already explained, sandboxing is orthogonal to packaging. >>>> >>>> Huh? How would you get sandboxing without Flatpaks? Unless you are >>>> proposing a different sandboxing technology. >>> >>> Things like libvirt-sandbox have been around for a really long time >>> and don't require special packaging (in fact they work with any >>> arbitrary command). >> >> reading between the lines of the fine documentation, there is no mention >> of X11 or GUI applications, so i guess "arbitrary" is a bit of an >> exaggeration? > > It seems like it's not mentioned in the docs, but it does work as in > this example of running evince to view a suspect PDF file: > > https://honk.sigxcpu.org/con/More_sandboxing.html says: Note that the above example shares /tmp with the sandbox in order to give it access to the X11 socket. A better isolation can probably be achieved using xpra or xvnc but I haven't looked into this yet. so it doesn't actually sandbox very much, with access to the X11 socket the app can keylog and inject shell commands into terminal windows as much as it likes. > BTW libvirt sandbox allows either full-virt or container sandboxing. i'd hope if you don't use containers but full-virt it's going to use something more secure, like SPICE or something to display the GUI? but i'd call virtualization a bit of a heavy-weight approach. ... there's more prior art, the SELinux "sandbox -X", which at least starts a nested Xephyr for your convenience. http://danwalsh.livejournal.com/31146.html http://danwalsh.livejournal.com/31247.html these have in common that they're generally not very user friendly: you have to set up which files the program will have access to when you start it; also copy/paste probably doesn't work between the nested X server, which may or may not be a feature. FlatPak portals have the potential to be more user friendly since you can use the application's normal file picker to open files and the application only gets access to the file the user chooses. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CUPS will change license since 2.3 version - now incompatible with GPLv2
On 08.11.2017 15:53, Hans de Goede wrote: > Hi, > > On 08-11-17 15:06, Solomon Peachy wrote: >> On Wed, Nov 08, 2017 at 08:54:03AM -0500, Neal Gompa wrote: >>> Is there anyone who could raise concerns to Apple about the license >>> change? Maybe convince them to dual-license it or something? >> >> Well, Michael Sweet (mswet AT apple.com) remains the primary developer >> of CUPS, and this has been raised on the CUPS mailing list in response >> to the announcement he posted. >> >> Here's the latest response [1] on that thread: >> >> I don't think static linking against libcups is common enough to be a >> serious concern - CUPS is fairly ubiquitous and easily falls under the >> "OS-supplied library" exception in the GPL 2. And existing GPL-2-only >> software that *does* statically link/copy CUPS code can continue to do >> so with CUPS 2.2.x and earlier. > > Someone should reply to that that the OS exception only applies when > distributing binaries separate from said OS, not for binaries bundled > with the OS, which all Linux distros are (AFAIK, IANAL). apparently Fedora Legal FAQ has a different opinion: https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F "However, we consider that the OpenSSL library is a system library, as defined by the GPL, on Fedora and therefore we are allowed to ship GPL software that links to the OpenSSL library." ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
orphaning German dictionary/thesaurus/hyphenation
hello, i've orphaned these linguistic packages for "de" languages: * hunspell-de this tends to have a new release once or twice a year * mythes-de upstream is a bit odd in that there is a new automatically generated .oxt file once per day, but the file name never changes... * hyphen-de this one never changes they are all up-to-date in rawhide/F28. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
