Hello all,
For use in libreoffice, chromium and others I've created macro that
should allow you to limit jobs based on some constraints you can set
later on in the spec to avoid OOM crashes.
The usage is pretty straight forward (Once it is accepted in
Tumbleweed):
===
BuildRequires: memory-constraints
%build
# require 2GB mem per thread
%limit_build -m 2000
make %{?_smp_mflags}
====
Here the _smp_mflags vaule for 8GB machine would be 4 while default is
number of cores (lets say 16)...
Both macros %jobs and %_smp_mflags are overriden as such the
integration should be really painless if you need to do something like
this.
Tom
Hello packagers,
the SUSE security team wants to draw your attention to a potential security
threat involving the use of `quilt setup ...` on untrusted RPM spec files.
For many of us calling `quilt setup $PACKAGE.spec` is probably a frequent part
of our daily workflows. In contrast to building a package on the server in an
isolated VM or on the client in a chroot via `osc build`, the `quilt setup`
runs without any isolation on the host in the calling user's context. As it
turns out this operation easily allows to execute code in the following ways:
- The statements in the `%prep` section of the RPM spec file are
unconditionally executed in the context of the calling user.
- Arbitrary flags can be passed to `patch` via `%define _default_patch_flags
...` in the spec file. By embedding semicolons into the flags also arbitrary
commands can be injected this way.
- By combining the available vectors, difficult to spot malicious code can be
hidden in RPM spec files. For example patch can be caused to follow
symlinks, thereby "patching" files in a user's home directory as demonstrated
in [1].
A demonstration works like this:
```sh
$ osc co home:mgerstner/surprise
$ cd home:mgerstner/surprise
$ quilt setup surprise.spec
# notice the surprise
$ bash
```
We have posted about this on the oss-security mailing list [2] to start a
discussion about possible countermeasures. A first aid could be to run the
`quilt setup` inside a docker container or in a similar isolated environment.
We are currently testing isolation of quilt with nsjail [3]. nsjail RPMs are
available for Leap 15 and Tumbleweed from its devel project [4]. It is
currently not found in Factory/Leap directly. Via the wrapper "squilt" [5],
nsjail is utilized to confine quilt to read only the files it needs and is
only able to write in the current directory. According to our initial testing
it can be used as a drop in replacement and should reduce the attack surface
significantly.
Our foremost intent is to make you aware of this so you don't run `quilt
setup` unsuspectingly on untrusted packages that did not go through review.
Furthermore to make you aware of how malicious code that targets this can be
embedded in spec files and patches. This should be taken into account when
reviewing package submissions.
If you have any questions or suggestions then please let's start a discussion.
[1]: https://build.opensuse.org/package/show/home:mgerstner/surprise
[2]: https://www.openwall.com/lists/oss-security/2018/09/27/2
[3]: http://nsjail.com
[4]: https://build.opensuse.org/package/show/security/nsjail
[5]: https://github.com/jsegitz/squilt
--
Matthias Gerstner <matthias.gerstner(a)suse.de>
Dipl.-Wirtsch.-Inf. (FH), Security Engineer
https://www.suse.com/security
Telefon: +49 911 740 53 290
GPG Key ID: 0x14C405C971923553
SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nuernberg)
Hi,
is there documentation about what rpm macros are available for packaging
plasma? A (casual) google search only returns documentation about macros
for KDE3 and KDE4.
Specifically: is there a plasma5 equivalent to
%kde4-runtime-requirements?
cheers
Mathias
Hi,
I'm having a really strange packaging issue on Leap 15.0:
the %files se4ction of my spec file fails!
here's the part of the spec file in question:
%files
%defattr(-,root,root,0755)
%doc $RPM_BUILD_DIR/%{_srcname}/build-linux-%{_arch}/newview/packaged/*.txt
%{prefix}
/usr/share/applications/*
/usr/share/pixmaps/*
/usr/games/*
%config /etc/permissions.d/%{name}
and here is the log output:
%files
2685s] Processing files: phoenix-firestorm-lgpl-5.1.9.56359-lp150.7.1.x86_64
[ 2685s] Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.ZJ8qDk
[ 2685s] + umask 022
[ 2685s] + cd /home/abuild/rpmbuild/BUILD
[ 2685s] + cd phoenix-firestorm-lgpl
[ 2685s] + DOCDIR=/home/abuild/rpmbuild/BUILDROOT/phoenix-firestorm-
lgpl-5.1.9.56359-lp150.7.1.x86_64/usr/share/doc/packages/phoenix-firestorm-
lgpl
[ 2685s] + export LC_ALL=C
[ 2685s] + LC_ALL=C
[ 2685s] + export DOCDIR
[ 2685s] + /usr/bin/mkdir -p /home/abuild/rpmbuild/BUILDROOT/phoenix-
firestorm-lgpl-5.1.9.56359-lp150.7.1.x86_64/usr/share/doc/packages/phoenix-
firestorm-lgpl
[ 2685s] + cp -pr /home/abuild/rpmbuild/BUILD/phoenix-firestorm-lgpl/build-
linux-x86_64/newview/packaged/FIRESTORM_DESKTOPINSTALL.txt /home/abuild/
rpmbuild/BUILD/phoenix-firestorm-lgpl/build-linux-x86_64/newview/packaged/
README-linux-joystick.txt /home/abuild/rpmbuild/BUILD/phoenix-firestorm-lgpl/
build-linux-x86_64/newview/packaged/README-linux-voice.txt /home/abuild/
rpmbuild/BUILD/phoenix-firestorm-lgpl/build-linux-x86_64/newview/packaged/
README-linux.txt /home/abuild/rpmbuild/BUILD/phoenix-firestorm-lgpl/build-
linux-x86_64/newview/packaged/VivoxAUP.txt /home/abuild/rpmbuild/BUILD/
phoenix-firestorm-lgpl/build-linux-x86_64/newview/packaged/
featuretable_linux.txt /home/abuild/rpmbuild/BUILD/phoenix-firestorm-lgpl/
build-linux-x86_64/newview/packaged/licenses.txt /home/abuild/rpmbuild/
BUILDROOT/phoenix-firestorm-lgpl-5.1.9.56359-lp150.7.1.x86_64/usr/share/doc/
packages/phoenix-firestorm-lgpl
[ 2685s] + exit 0
[ 2685s] error: File not found by glob: /home/abuild/rpmbuild/BUILD/phoenix-
firestorm-lgpl/$RPM_BUILD_DIR/phoenix-firestorm-lgpl/build-linux-x86_64/
newview/packaged/*.txt
[ 2685s]
[ 2685s]
[ 2685s] RPM build errors:
[ 2685s] File not found by glob: /home/abuild/rpmbuild/BUILD/phoenix-
firestorm-lgpl/$RPM_BUILD_DIR/phoenix-firestorm-lgpl/build-linux-x86_64/
newview/packaged/*.txt
[ 2685s]
[ 2685s] lamb78 failed "build phoenix-firestorm-lgpl.spec" at Sun Sep 23
05:42:03 UTC 2018.
On every suse version until now this had worked just fine, but on 15.0 it
almost looks as if $RPM_BUILD_DIR is not defined anymore, or as if variables
are not expanded anymore at that point.
Any ideas?
--
Mathias Homann
Senior Systems Engineer, IT Consultant. IT Trainer
Mathias.Homann(a)openSUSE.org
http://www.tuxonline.tech
gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Hi, I made the decision to put the three libraries in sub package
libjack0 into their own sub packages, we now have libjack0, libjacknet0
and libjackserver0. None of these libraries are dependent on the others.
A lot of opensuse packages require libjack0 but the only package that
depends on libjacknet0 and libjackserver0 are binaries in the jack package.
I previously had libjacknet0 and libjackserver0 require libjack0 =
%{version} which in my mind is wrong and rpmlint doesn't like it either.
I've removed the two requires and modified the "obsoletes libjack0 <
%{version}" to "obsoletes libjack0 < 1.9.12" (the version that the
package was split).
libjacknet0 and libjackserver0 naturally provide themselves.
My question is - isn't the obsoletes enough for libjacknet0 and
libjackserver0?
Thanks
Dave P
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
darktable-2.5.0~git461.cc742b6d0-300.1.x86_64.rpm
* Sun Sep 09 2018 opensuse-packaging(a)opensuse.org
- Update to version 2.5.0~git461.cc742b6d0:
* RawSpeed submodule update: does anyone actually read this though?
* Olympus E-PL8 color matrix
* Pentax 645z: official color matrix from DNG
* Pentax 645D: use official color matrix from DNG
* Olympus SH-2 color matrix
* Updated Dutch translation
* Add some more consts in retouch iop.
* Update French translation.
* Retouch GUI (#1550)
* Update French translation.
yes, for every build
tks
--
(paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri
http://en.opensuse.org openSUSE Community Member facebook/ptilopteri
Registered Linux User #207535 @ http://linuxcounter.net
Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
Trying to compile syslog-ng in my repo both for SLE_15 and
SLE_15_backports and ran into something interesting. I use the
following to detect SLES, and it works fine for the SLE_15 variant.
But for SLE_15_backports I get "nothing provides
riemann-c-client-devel"
# riemann does not compile on SLES
%if !0%{?is_opensuse}
%bcond_with riemann
%else
%bcond_without riemann
%endif
Any clues why the above does not work for backports?
Bye,
CzP
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi all,
I'm trying to find out how I can solve diverging changelogs in SLE/Leap
and Factory. There were some patches in SLE12 SP3, which are not needed
(and are in fact harmful) in SLE12 SP4.
1. When I take the Factory package and submit it to SLE12 SP4, the
submission gets rejected, because some (SP3) patches are not
mentioned in the changelog.
2. When I start with the SP3 package and update it manually,
leaperbot complains that it does not follow Factory first policy.
Release managers tell me I should merge the changes in Factory and
resubmit.
3. When I submit the merged changelog, the request gets declined:
https://build.opensuse.org/request/show/632515
Is the correct process to keep a non-working makedumpfile in SLE12 SP4
and wait until the situation gets escalated by a SUSE partner during
Beta testing (which is what I did, effectively)?
Please, advise.
TIA,
Petr T
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
