Bug#1069576: blhc: False positive NONVERBOSE BUILD in src:fim
Hi Rafael,
On Sat, Apr 20, 2024 at 09:13:58PM +0200, Rafael Laboissière wrote:
> Dear Maintainer,
>
> blhc triggers a NONVERBOSE BUILD error in src:fim
>
> https://salsa.debian.org/debian/fim/-/jobs/5618524
>
> [snip]
> $ blhc --debian --line-numbers --color ${SALSA_CI_BLHC_ARGS}
> ${WORKING_DIR}/*.build || [ $? -eq 1 ]
> 338:NONVERBOSE BUILD: CXX : g++
> [snip]
>
> blhc is complaining about the output of the upstream configure script,
> which indicates to the user which C++ compiler will be used.
should be fixed in [1].
> The patch attached to this bug report fixes the problem for me.
> Hopefully, it will not introduce false negatives.
Thanks for the patch. I've fixed it slightly differently to
reduce the chance of false negatives.
Best,
Simon
[1]
https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=5d2c33804eade9a6b1463d4cb46d7cac0018274c
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
signature.asc
Description: PGP signature
Bug#1037521: (no subject)
Hi, On Fri, Apr 05, 2024 at 12:48:19AM -0400, Yogeswaran Umasankar wrote: > eribe...@debian.org, Matthias Geiger > Bcc: Subject: Re: false positive NONVERBOSE BUILD for rust code in Python > modules > Reply-To: Hi, > > I am having similar issue in another package 'python-cotengrust' [0]. > The link for buildlog [1]. > > [0] https://salsa.debian.org/python-team/packages/python-cotengrust/ > [1] > https://salsa.debian.org/python-team/packages/python-cotengrust/-/jobs/5519541 as discussed in IRC the problem is that blhc cannot detect that this is a rust package. In regular buildd logs the "Filtered Build-Depends:" lines contain the build dependencies. This gives blhc a way to enable special handling for certain situations (in this case if a rust compiler is used). I couldn't find a way to get this information from the salsa build logs. If they could be modified to show the build dependencies then I'll adapt blhc to detect this case. Best, Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#1068773: Subject: blhc: Stack clash and branch protection flag issues in Debian Bookworm and older releases
Hi,
On Wed, Apr 10, 2024 at 09:09:13PM +, aquilamac...@riseup.net wrote:
> The ${RELEASE} variable in the context of this issue refers to the
> specific Debian release being used during the Salsa CI process. One
> potential solution that has been considered is to ensure that
> blhc:${RELEASE} correctly handles the flags for each release. This
> approach could alleviate the compilation errors and ensure consistency
> across different Debian releases.
>
> For more details, you can check the issue in the Salsa CI repository at
> https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/340
>
> Before proceeding with any changes, I would appreciate your input on
> this matter. Specifically, do you think it would be sensible to use blhc
> from each release? Your insights would be greatly appreciated.
I think the best solution is to use the blhc version from the
corresponding release (i.e. blhc:${RELEASE}). Otherwise each
change to flags in blhc will require manual work for earlier
releases as carnil mentioned.
The blhc version in each release should be able to handle the
flags for that release (otherwise it's a bug which should be
fixed). So the suggested first approach should work fine and
cause the less additional maintenance overhead.
Best,
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
signature.asc
Description: PGP signature
Bug#1037521: false positive NONVERBOSE BUILD for rust code in Python modules
Hi, 0.14 fixed some rust related issues. Could you please retest with the latest version? If it still fails please provide the full build log so I can easily replicate it (didn't find an obvious way to download the raw build log from salsa). Best, Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#1050912: blhc: Please add support for -mbranch-protection=standard (arm64) and -fcf-protection (amd64)
Hallo Emanuele, On Thu, Aug 31, 2023 at 01:29:44PM +0200, Emanuele Rocca wrote: > Hi, > > the flag -mbranch-protection=standard has been added to the default > build flags for arm64, and -fcf-protection for amd64, since dpkg 1.22.0. > > It would be great if blhc could add support for both. > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021292 and > https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=8f5aca71c also now implemented in blhc [1]. Best, Simon [1]: https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=019d2b1c80b43bc7fa2a1df68ca3fa4f81569961 -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#1050909: blhc: Please add support for -fstack-clash-protection
Hi, sorry for the late response. On Thu, Aug 31, 2023 at 01:24:04PM +0200, Emanuele Rocca wrote: > Hi, > > the flag -fstack-clash-protection has been added to the default build > flags for amd64, arm64, armhf, and armel in dpkg 1.22.0. > > It would be great if blhc could add support for it. > > See https://bugs.debian.org/918914 and > https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=11efff1bf Thanks for the links. It's now implement in blhc [1]. Best, Simon [1]: https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=f1ac73364a8d0a20e279328db6b6e1e8dbfe9a4e -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#1043522: blhc: Please allow -std=gnu++20 inside bin/blhc:L1114 regex exception
Hi Marco, sorry for the late response. On Sat, Aug 12, 2023 at 02:14:37PM +0200, Marco Mattiolo wrote: > Dear Maintainer, > > while building an app (Calindori, calendar for Plasma mobile) to be included > in Debian, I found what I think is an issue with blhc: in [1] it is found > > |/usr/lib/ccache/c++ -std=gnu++20 -dM -E -c > /usr/share/cmake-3.27/Modules/CMakeCXXCompilerABI.cpp| This is now fixed in blhc [1] [2]. Best, Simon [1]: https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=766e4499437c6e872cc5870a821c4d10d2d8a63b [2]: https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=33f9f4721b73fb4789bff5670cbde41b23071106 -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#1054882: blhc: False positive: CPPFLAGS missing (-D_FORTIFY_SOURCE=2): /usr/share/cmake-3.27/Modules/CMakeCXXCompilerABI.cpp
Hi Soren,
sorry for the late response.
On Fri, Dec 15, 2023 at 01:16:38AM -0700, Soren Stoutner wrote:
> [snip]
>
> # cmake checking for compiler flags without setting CPPFLAGS
> next if $line =~ m{^\s*/usr/(bin|lib)/(ccache/)?c\+\+ -dM -E -c
> /usr/share/cmake-\S+/
> Modules/CMakeCXXCompilerABI\.cpp};
>
> https://ruderich.org/simon/gitweb/?p=blhc/
> blhc.git;a=commitdiff;h=32513c3cf648aab94fb011e488a79bb38c2fafd1[2]
>
> I am not a regular expression expert, and it seems that both of these ought
> to match
> against the line in question:
>
> /usr/bin/c++ -std=gnu++11 -dM -E -c /usr/share/cmake-3.27/Modules/
> CMakeCXXCompilerABI.cpp
The problem was the -std=gnu++11 which mas missing in the regexp,
now fixed in [1].
Best,
Simon
[1]:
https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=766e4499437c6e872cc5870a821c4d10d2d8a63b
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
signature.asc
Description: PGP signature
Bug#1050942: FTBFS: Failed 1/1 test programs. 5/246 subtests failed.
On Thu, Aug 31, 2023 at 01:29:17PM -0300, Joao Eriberto Mota Filho wrote: > Dear Simon Ruderich, > > Currently blhc fails to build from source in Debian Sid. This issue was > detected in Salsa[1]. > > [1] https://salsa.debian.org/debian/blhc/-/jobs/4635438 Hi Eriberto, should be fixed in fb2c46d [2]. Best, Simon [2]: https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=fb2c46d23c6052c714729d70d33d54011374689b -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#1035432: blhc: Warnings for Linux 6.3 build
Hi Uwe, On Sun, May 07, 2023 at 09:17:48AM +0200, Uwe Kleine-König wrote: > The idea is to have several ignore-line-regexp specs, where each is simpler > and can be documented individually. However that doesn't work as blhc only > uses one of them (don't remember, probably the first or the last). > > I would consider it a very nice feature of blhc to support using them all. > Now that the original bug is degraded to a RTFM, I made this bug a wishlist > item for this feature. using multiple "ignore-linx-regexp" is supposed to work (just checked the source and there's also a test with multiple ignore-line-regexps). Could you provide a sample build log where it fails? Best, Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#1035432: blhc: Warnings for Linux 6.3 build
On Wed, May 03, 2023 at 12:21:02PM +0200, Uwe Kleine-König wrote: > Do you have a nice idea how to fix the test that does involve neither > disabling the blhc tests nor disabling the perf tests? One idea is to > not check debug builds (-Og or -O0) for the fortify stuff. Another is to > allow specifying a regexp of (possible) false positives. Hi Uwe, the method suggested by Diederik [1] is the recommended way to handle false positives in blhc. It's documented in the blhc man page: man blhc | less -p 'FALSE POSITIVES': To suppress false positives you can embed the following string in the build log: blhc: ignore-line-regexp: REGEXP All lines fully matching REGEXP (see --ignore-line for details) will be ignored. [...] On Wed, May 03, 2023 at 02:06:21PM +0200, Diederik de Haas wrote: > Note that there was already a 'workaround'* for a similar (?) case: > https://salsa.debian.org/kernel-team/linux/-/commit/9bbf3331de0772f65605ed7d545e086749474aa4 > > *) I lack the knowledge whether it's a workaround, the intended way to deal > with such things or something else > > Maybe there are more such cases where the `blhc` job would fail in Salsa's CI > and for which there isn't yet a facility in blhc. If that's the case then such > a generic facility could be useful. > Or a 'feature' could/should be added to Salsa's pipeline definition which > makes > it (easy and) uniform to declare such cases. It's difficult/impossible to handle these cases in a general way. Using the above ignore is the best solution I know of. Best, Simon [1] https://salsa.debian.org/kernel-team/linux/-/commit/9bbf3331de0772f65605ed7d545e086749474aa4 -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#1033027: blhc: misinterprets nvcc compilation as linking
On Wed, Mar 15, 2023 at 11:31:01PM +0100, Andreas Beckmann wrote: > Hi, > > blhc seems to misparse nvcc compilation as linking, reporting missing > LDFLAGS: Hi Andreas, should be fixed in 21f2f4 [1]. Best, Simon [1]: https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=21f2f49049ef599e6d7116c815e5974b2fcdd505 -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#1004797: xpra: FTBFS with ffmpeg 5.0
Hi, upgrading to xpra 3.1.3 (latest 3.1 release) also fixes this bug. The existing debian/ builds fine with 3.1.3, only the systemd.patch needs to be removed (no longer necessary as upstream now uses /etc/default/xpra). Best, Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#1027084: blhc: recognize _FORTIFY_SOURCE level 3
On Tue, Dec 27, 2022 at 05:48:20PM +0100, Christian Göttsche wrote: > Please recognize -D_FORTIFY_SOURCE=3 as fortification enabled. Hi, should be implemented with [1]. Please test. Best, Simon [1] https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=88f15389b533468857f01490368376b539a598b3 -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#784182: blhc: warns about disabled flags
On Fri, Sep 30, 2022 at 11:19:16AM +0200, IOhannes m zmoelnig wrote: > i've bumped into this with my 'o2' builds (which also uses "-fortify") on > salsa, so it is not really "fixed" (as of 2022-09) > > of course i could add a 'blhc: ignore-line-regexp:', but in practice that > would disable the entire blhc check. > or I could add some "--ignore-flag -D_FORTIFY_SOURCE=2" to the invocation > of blhc. > but really i'd like to not do this, as it requires me to manually check > which flags get disabled by which DEB_BUILD_MAINT_OPTIONS=hardening option > and fix this blhc-invocation whenever a package requires special hardening > flags... Hi IOhannes, I'm somewhat out of the loop regarding Debian's build process. Is this something blhc can extract from the build log? Best, Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#1019521: blhc: False positive for Qt6 moc
On Wed, Dec 21, 2022 at 11:00:56AM -0300, Eriberto wrote: > Hi Simon, > > Could you check the patch below? > > Regards, > > Eriberto > > Em qua., 21 de dez. de 2022 às 03:51, Ross Vandegrift > escreveu: >> >> Package: blhc >> Version: 0.13-2 >> Followup-For: Bug #1019521 >> X-Debbugs-Cc: rvandegr...@debian.org >> >> Hello, >> >> I also ran into this- moc is now at /usr/lib/qt6/libexec/moc. I think the >> attached patch should address this. Hi Ross, thanks for the patch. Looks good. Pushed to [1]. Best, Simon [1] https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=018466d7ddd9c78f1e1efbafbb7be2f969e1bbd1 -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#898333: CMake trouble
On Sat, Jul 02, 2022 at 01:58:06AM -0400, Ben Westover wrote: > It turns out that the debian/rules line works if I remove the start and end > characters (in this case the quotes). > This should either be changed so that --ignore-line and the debian/rules > string use the same format, or it should be documented. Could you provide me with both failing and working debian/rules and the corresponding build logs? Best, Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#898333: CMake trouble
On Fri, Jul 01, 2022 at 03:28:51AM -0400, Ben Westover wrote: > I attempted to make blhc ignore this by echoing > "blhc: ignore-line-regexp: \.S", but it didn't work. I also tried to run > blhc with the actual --ignore-line flag, but it was still picking up > those lines. I even did a simplified "--ignore-line asm", but it still > doesn't work. Just in case, I tried again with "/asm/". This is all > valid Perl regex, but it seems like blhc just isn't working at all here. > Am I doing something wrong? Hi Ben, to quote the man-page: > Ignore lines matching the given Perl regex. regex is > automatically anchored at the beginning and end of the line to > prevent false negatives. > > NOTE: Not the input lines are checked, but the lines which are > displayed in warnings (which have line continuation resolved). Something like --ignore-line '/usr/bin/cc.*\S+\.S' should work. Best, Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#980609: missing i386-cpuinfo.h
Hello,
the attached patch works for me as workaround for Bullseye. It adds the
missing file and updates the #include path to it. Apply it with
cd / && patch -p1 < /path/to/patch
With the patch I can successfully build kernels which use GCC
plugins on Bullseye.
Is it possible to apply a similar patch to the official gcc
package distributed in Bullseye? Having to patch the systems
manually isn't optimal.
Regards
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
Workaround for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980609, based
on pr95842.diff
Apply with cd / && patch -p1 < /path/to/patch
--- a/usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/config/i386/i386.h.orig 2021-01-10 12:35:39.0 +0100
+++ b/usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/config/i386/i386.h 2022-01-23 10:22:59.579197064 +0100
@@ -2497,7 +2497,7 @@
#include "insn-attr-common.h"
-#include "common/config/i386/i386-cpuinfo.h"
+#include "config/i386/i386-cpuinfo.h"
class pta
{
--- /dev/null
+++ b/usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/config/i386/i386-cpuinfo.h
@@ -0,0 +1,134 @@
+/* Get CPU type and Features for x86 processors.
+ Copyright (C) 2012-2020 Free Software Foundation, Inc.
+ Contributed by Sriraman Tallam (tmsri...@google.com)
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
+
Bug#994422: blhc: False positive: CPPFLAGS missing (-D_FORTIFY_SOURCE=2): /usr/lib/ccache/c++ -dM -E -c /usr/share/cmake-3.16/Modules/CMakeCXXCompilerABI.cpp
On Tue, Oct 05, 2021 at 05:42:47PM -0300, Eriberto wrote: > Em ter., 5 de out. de 2021 às 07:41, Simon Ruderich > escreveu: >> >> On Wed, Sep 15, 2021 at 06:23:12PM -0300, Eriberto Mota wrote: >>> Complementing, my local build jail uses /usr/bin/c++, but Salsa uses >>> /usr/lib/ccache/c++. Consequently, my current rule in debian/rules is: >>> >>> @echo 'blhc: ignore-line-regexp: /usr/(bin|lib)/(ccache/)?c\+\+ -dM -E >>> -c /usr/share/cmake-[0-9.]+/Modules/CMakeCXXCompilerABI.cpp .*' >> >> Hello Eriberto, >> >> thanks for the report and the patch. I've implemented it (with a >> slightly different regex) in [1]. Please check if this fixes the >> issue for your cases as well (didn't find any full build logs >> with this issue) and I'll release a new version of blhc with the >> fix. > > Hi Simon, > > Worked fine on my machine. I think it will work for Salsa too. This > package[1] is waiting in NEW and has a build log with this issue. I > put a regex in debian/rules to ignore the issue. I also maintain this > package[2] with the same issue. > > [1] https://salsa.debian.org/debian/obs-advanced-scene-switcher > [2] https://salsa.debian.org/debian/packetsender > > Thanks! Thanks! Hello Eriberto, perfect, thanks for testing. I've just released blhc 0.13 with all recent fixes. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#975650: blhc: reports false positives for missing flags
On Tue, Oct 05, 2021 at 09:32:21PM +0200, Fabian Wolff wrote: > On 10/5/21 1:48 PM, Simon Ruderich wrote: >> Could you test the attached patch and tell me if this works for >> you for real builds? > > Thankfully, I still had the full log file lying around in which I > originally discovered this issue, and I am indeed no longer getting > any false positives with your patch. (I don't know whether this causes > any new false negatives, but I suppose you have other tests for this?) > > Thanks for your work on this! Hello Fabian, thanks for testing. I've just released blhc 0.13 with the fix. I don't that it should cause false negatives. Regards Simon -- + Privatsphäre ist notwendig + Ich verwende GnuPG http://gnupg.org + Öffentlicher Schlüssel: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#975650: blhc: reports false positives for missing flags
On Sun, Nov 29, 2020 at 07:21:48PM +0100, Fabian Wolff wrote:
> On 11/28/20 10:47 PM, Eriberto wrote:
>> Thanks Fabian and Simon!
>>
>> Considering that some false positives can't be fixed in blhc source
>> code, could I close this bug?
>
> I think it would make more sense to close this bug with the next
> upstream release, given that some changes in blhc have been applied
> because of it (commit 79d3a9e in the upstream repository), and it's
> also mentioned in the NEWS entry for the next release.
Hello Fabian,
sorry for the late reply. While looking at Olaf's report I also
thought about your original report and I might have a (partial)
solution.
The problem in this case is only the compiler detection, not
actually handling environment variables. So stripping them should
be enough. I've implemented a patch which strips (basic)
environment variables (no nested quotes, command substitution,
etc.).
Could you test the attached patch and tell me if this works for
you for real builds?
Regards
Simon
--
+ Privatsphäre ist notwendig
+ Ich verwende GnuPG http://gnupg.org
+ Öffentlicher Schlüssel: 0x92FEFDB7E44C32F9
From 5cb3ea785d8c4602a703336797f42295d1980827 Mon Sep 17 00:00:00 2001
Message-Id: <5cb3ea785d8c4602a703336797f42295d1980827.1633434227.git.si...@ruderich.org>
From: Simon Ruderich
Date: Tue, 5 Oct 2021 13:43:29 +0200
Subject: [PATCH] Strip (basic) environment variables before compiler detection
---
bin/blhc | 20 +++-
t/tests.t | 4 ++--
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/bin/blhc b/bin/blhc
index 2f8da5f..d41ff88 100755
--- a/bin/blhc
+++ b/bin/blhc
@@ -1022,9 +1022,27 @@ foreach my $file (@ARGV) {
$complete_line = undef;
}
+my $noenv = $line;
+# Strip (basic) environment variables for compiler detection.
+# Nested quotes, command substitution, etc. is not supported.
+$noenv =~ s/^
+\s*
+(?:
+[a-zA-Z_]+ # environment variable name
+=
+(?:
+[^\s"'\$\\]+# non-quoted string
+|
+'[^"'\$`\\]*' # single-quoted string
+|
+"[^"'\$`\\]*" # double-quoted string
+)
+\s+
+)*
+//x;
# Ignore lines with no compiler commands.
next if not $non_verbose
-and not $line =~ /$cc_regex_normal/o;
+and not $noenv =~ /$cc_regex_normal/o;
# Ignore lines with no filenames with extensions. May miss some
# non-verbose builds (e.g. "gcc -o test" [sic!]), but shouldn't be
# a problem as the log will most likely contain other non-verbose
diff --git a/t/tests.t b/t/tests.t
index b4c0352..737f3ec 100644
--- a/t/tests.t
+++ b/t/tests.t
@@ -633,8 +633,8 @@ CPPFLAGS missing (-D_FORTIFY_SOURCE=2): gcc -g -O2 -fstack-protector-strong -Wfo
LDFLAGS missing (-fPIE -pie -Wl,-z,relro -Wl,-z,now): gcc -g -O2 -fstack-protector-strong -Wformat -Wformat-security -Werror=format-security test.c -o lib`basename test/test`.so
';
-is_blhc 'env', '--all', 8,
-'CPPFLAGS missing (-D_FORTIFY_SOURCE=2): VERSION=v-amd64-linux CPP="gcc -x assembler-with-cpp -E -P -Wdate-time -D_FORTIFY_SOURCE=2" CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" ../../config/gen-posix-names.sh _SC_ ml_sysconf.h
+is_blhc 'env', '--all', 1,
+'No compiler commands!
';
--
2.33.0
signature.asc
Description: PGP signature
Bug#975650: blhc: reports false positives for missing flags
On Sun, Feb 21, 2021 at 03:24:26PM -0500, Olek Wojnar wrote: > I have run into this exact issue with bazel-bootstrap builds. [1] I love > what blhc does so I'd rather not disable it due to these false positives, > but I also like for the Salsa CI to let me know when a recent commit has > caused a problem, and constant test failures mask that. > > Would it be possible to change the regex so that it will also accept a " or > a ' next to the spaces surrounding the flag? That way all of the three > following would be considered valid: > -D_FORTIFY_SOURCE=2 > '-D_FORTIFY_SOURCE=2' > "-D_FORTIFY_SOURCE=2" Hello Olek, sorry for the late reply. The issue you mentioned is different from the originally reported bug and much easier to fix. Should be fixed with [1], please check and report back. The original issue is that blhc treats the line as a compiler line because it sees the "gcc" in the environment variable (not noticing that it's just an environment variable and not a command). > Thanks for your work on this package, it's a very useful indicator of > regressions or other coding issues! You're welcome! Regards Simon [1]: https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=06b7783ef223d0f58804f3f08d27c45dc3b97351 -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#994422: blhc: False positive: CPPFLAGS missing (-D_FORTIFY_SOURCE=2): /usr/lib/ccache/c++ -dM -E -c /usr/share/cmake-3.16/Modules/CMakeCXXCompilerABI.cpp
On Wed, Sep 15, 2021 at 06:23:12PM -0300, Eriberto Mota wrote: > Complementing, my local build jail uses /usr/bin/c++, but Salsa uses > /usr/lib/ccache/c++. Consequently, my current rule in debian/rules is: > > @echo 'blhc: ignore-line-regexp: /usr/(bin|lib)/(ccache/)?c\+\+ -dM -E > -c /usr/share/cmake-[0-9.]+/Modules/CMakeCXXCompilerABI.cpp .*' Hello Eriberto, thanks for the report and the patch. I've implemented it (with a slightly different regex) in [1]. Please check if this fixes the issue for your cases as well (didn't find any full build logs with this issue) and I'll release a new version of blhc with the fix. Regards Simon [1] https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=32513c3cf648aab94fb011e488a79bb38c2fafd1 -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#987126: golang-1.16: Fails to build anything due to missing files: undefined: StackGuardMultiplierDefault
Package: golang-1.16
Version: 1.16.3-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: si...@ruderich.org
Hello,
since the update to 1.16.3-1 I cannot build any packages with
go-1.16:
$ printf 'package main\nmain(){}' > x.go
$ /usr/lib/go-1.16/bin/go run x.go
# runtime/internal/sys
/usr/lib/go-1.16/src/runtime/internal/sys/stubs.go:16:30: undefined:
StackGuardMultiplierDefault
It looks like some files are missing from golang-1.16-src:
$ debdiff golang-1.16-src_1.16-1_amd64.deb golang-1.16-src_1.16.3-1_all.deb
Files in second .deb but not in first
-
[...]
Files in first .deb but not in second
-
-rw-r--r-- root/root /usr/share/go-1.16/src/cmd/cgo/zdefaultcc.go
-rw-r--r-- root/root
/usr/share/go-1.16/src/cmd/go/internal/cfg/zdefaultcc.go
-rw-r--r-- root/root
/usr/share/go-1.16/src/cmd/go/internal/cfg/zosarch.go
-rw-r--r-- root/root
/usr/share/go-1.16/src/cmd/internal/objabi/zbootstrap.go
-rw-r--r-- root/root /usr/share/go-1.16/src/go/build/zcgo.go
-rw-r--r-- root/root
/usr/share/go-1.16/src/runtime/internal/sys/zversion.go
[...]
Downgrading to 1.16-1 works fine.
Regards
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
signature.asc
Description: PGP signature
Bug#975650: blhc: reports false positives for missing flags
On Tue, Nov 24, 2020 at 05:16:03PM +0100, Fabian Wolff wrote: > Dear maintainer, > > consider the following warnings emitted by blhc (line breaks are mine; > see the attached "test.log" file for an input that reproduces this > problem): > > [snip] Hello Fabian, thanks for the sample log to easily replicate the issue. > One could argue whether blhc should even consider lines like these, > because they do not actually contain any compiler calls; perhaps it > would be more sensible to delay the warnings to the actual compiler > calls that the recursive make or the script perform. However, it > doesn't hurt to be on the safe side and check calls like these, too. > > The problem is that the reportedly missing flags aren't missing at > all: The former call contains "-Wl,-z,relro" in both CFLAGS and > LDFLAGS; the latter call contains "-D_FORTIFY_SOURCE=2" in both CPP > and CPPFLAGS. > > So, why does blhc think that those flags are missing? blhc uses a few heuristics to detect lines with (possible) compiler commands to prevent false negatives. Lines containing `gcc` and similar are flagged. In this case the CC= environment variable triggers this. Then blhc looks for the actual build command and its flags. Here the quote after -D_FORTIFY_SOURCE=2 is the problem because blhc requires a space after each flag. I know this handling is not perfect but parsing arbitrary shell commands is difficult. I've just pushed a fix for the `make` case which is easily fixable without causing false negatives (all make commands are now simply ignored). In addition, I improved the line splitting so something like `make && gcc test.c` now correctly triggers a warning (in the past lines were split only on ";", now "&&" and "||" are also considered; I hope this won't cause too many false positives). However, the second command is more difficult to fix because it would require stripping all environment variables from each command. Although possible it would be quite slow and complex (escaping and nested quotes must be considered). I think in this case the simplest solution is to manually ignore the line with "blhc: ignore-line-regexp: REGEXP" in debian/rules. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#975395: anki: Fails with Python3.9 due to use of deprecated unescape() method
Package: anki
Version: 2.1.15+dfsg-2
Severity: normal
Tags: patch
Hello,
since the update to python3.9 Anki fails with the following
exception when reviewing more complex HTML templates:
: 'HTMLParser' object has no attribute 'unescape'
The following patch fixes this issue for me:
--- /usr/share/anki/aqt/reviewer.py.orig2019-08-27 07:24:40.0
+0200
+++ /usr/share/anki/aqt/reviewer.py 2020-11-21 16:49:53.517798570 +0100
@@ -353,13 +353,12 @@
buf = buf.replace("", "")
hadHR = len(buf) != origSize
# munge correct value
-parser = html.parser.HTMLParser()
cor = self.mw.col.media.strip(self.typeCorrect)
cor = re.sub("(\n||)+", " ", cor)
cor = stripHTML(cor)
# ensure we don't chomp multiple whitespace
cor = cor.replace(" ", "")
-cor = parser.unescape(cor)
+cor = html.parser.unescape(cor)
cor = cor.replace("\xa0", " ")
cor = cor.strip()
given = self.typedAnswer
It looks like unescape() was never intended to be exposed via the
HTMLParser() object. But since Python 3.4 html.parser provides it
directly.
Regards
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
signature.asc
Description: PGP signature
Bug#973870: linux: Please consider enabling CONFIG_DEBUG_INFO_BTF
Hello, it would be great if this makes it into Bullseye. BTF is not only relevant for tracing but for all BPF-related tasks, including for example XDP. According to [1], most other distributions (Fedora 31+, RHEL 8.2+, Arch Linux, Ubuntu 20.10+) already enable BTF. Having this in the next Debian release would be very useful. I installed the dwarves package and tested building the linux source package with CONFIG_DEBUG_INFO_BTF and it worked fine. Regards Simon [1] https://github.com/libbpf/libbpf#bpf-co-re-compile-once--run-everywhere -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#948009: blhc: Don't scan dwz invocations seen with DH_VERBOSE=true
On Sat, Jan 04, 2020 at 03:35:04PM -0300, Eriberto wrote:
> Em sáb., 4 de jan. de 2020 às 08:18, Simon Ruderich
> escreveu:
>>
>> thanks for the build log, fixed in f0a9d41 ("Fix false positive
>> in `dwz` lines", 2020-01-04) [1].
>
> Hi Simon,
>
> Can you provide a new release?
Hi Eriberto,
done; I just released 0.11.
Regards
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
signature.asc
Description: PGP signature
Bug#948009: blhc: Don't scan dwz invocations seen with DH_VERBOSE=true
On Sat, Jan 04, 2020 at 11:57:02AM +0100, Raphael Hertzog wrote:
> Hi,
>
> On Sat, 04 Jan 2020, Simon Ruderich wrote:
>> On Fri, Jan 03, 2020 at 10:44:10AM +0100, Raphaël Hertzog wrote:
>>> https://salsa.debian.org/pkg-security-team/aflplusplus/-/jobs/481494/raw
>>
>> Hello,
>>
>> could you please provide me with the full raw (= text-only) build
>> log so I can reproduce this?
>
> https://buildd.debian.org/status/fetch.php?pkg=aflplusplus=amd64=2.60c-1=1578051979=1
>
> This newer build log also triggers other legitimate errors but it still
> has the invalid catch on the dwz invocation.
Hello,
thanks for the build log, fixed in f0a9d41 ("Fix false positive
in `dwz` lines", 2020-01-04) [1].
Regards
Simon
[1]
https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=f0a9d412466ca504fb2e279e1d98718a9c2bab28
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
signature.asc
Description: PGP signature
Bug#948009: blhc: Don't scan dwz invocations seen with DH_VERBOSE=true
On Fri, Jan 03, 2020 at 10:44:10AM +0100, Raphaël Hertzog wrote: > https://salsa.debian.org/pkg-security-team/aflplusplus/-/jobs/481494/raw Hello, could you please provide me with the full raw (= text-only) build log so I can reproduce this? Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#895462: Please keep asciidoc in Debian
On Wed, Dec 11, 2019 at 06:41:15PM -0800, Joseph Herlant wrote: > Hi Simon, > > I'd be interested in your use case. Do you have some examples of what > you call "proper localization with support for multiple languages and > flexibility through additional config files"? > > I also work with asciidoctor so I'd be happy to see with them if > upstream has that on their backlog. Hello Joseph, sure, my main use case for asciidoc is to generate static websites. Asciidoc supports setting the language attribute to generate localized output (e.g. proper quotes when using ``..'' which results in „...“ for German texts or captions like "Table"/"Tabelle"). From what I know that's not possible with asciidoctor. Asciidoc also has the nice feature of using configuration files to extend the syntax. For example: [quotes] ,,=#small [tags] small=| Then I can use ,,foo,, in the text and it will be converted to foo. > To be honest, asciidoc hasn't been really active over the last few > years (since its creator left the project) and even the current > maintainers have advise several times to switch to asciidoctor (which > has become the official reference for the asciidoc language), so the > package does now support python3, yes, but I would still advise to > look at alternatives long term. Another issue with asciidoctor, unrelated to its features, is that the output changes when compared to asciidoc. This is not a big issue but adds additional work during the conversion. So staying with asciidoc is simpler. Having an inactive project is in my opinion not an issue. Asciidoc is stable and works just fine and I didn't notice any major bugs so I'm not worried if it doesn't receive many updates. > The reason I keep this one open for now is to make sure people realize > that it's not because the language name is asciidoc that they should > use the asciidoc binary. That's a good point. For most people asciidoctor works fine (and I'm using it for some other projects). Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#945391: asciidocapi: fails with AttributeError: 'NoneType' object has no attribute 'loader'
Package: asciidoc
Version: 8.6.10+git20190307.51d7c14-1
Severity: normal
Tags: patch
Hello,
using asciidocapi with the following small script (also attached)
#!/usr/bin/python3
import io
import sys
sys.path.append('/usr/share/asciidoc')
import asciidocapi
infile = io.StringIO('Test')
outfile = io.StringIO()
adoc = asciidocapi.AsciiDocAPI()
adoc.execute(infile, outfile)
results in an exception:
Traceback (most recent call last):
File "./test", line 13, in
adoc = asciidocapi.AsciiDocAPI()
File "/usr/share/asciidoc/asciidocapi.py", line 209, in __init__
self.__import_asciidoc()
File "/usr/share/asciidoc/asciidocapi.py", line 244, in __import_asciidoc
module = importlib.util.module_from_spec(spec)
File "", line 580, in module_from_spec
AttributeError: 'NoneType' object has no attribute 'loader'
The attached patch fixes this issue (tested with python3.7 and
python3.8).
Regards
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
#!/usr/bin/python3
import io
import sys
sys.path.append('/usr/share/asciidoc')
import asciidocapi
infile = io.StringIO('Test')
outfile = io.StringIO()
adoc = asciidocapi.AsciiDocAPI()
adoc.execute(infile, outfile)
--- /usr/share/asciidoc/asciidocapi.py.orig 2019-11-19 08:27:07.987333977 +0100
+++ /usr/share/asciidoc/asciidocapi.py 2019-11-24 08:23:19.141730508 +0100
@@ -239,9 +239,13 @@
import imp
module = imp.load_source('asciidoc', self.cmd)
else:
-import importlib.util
-spec = importlib.util.spec_from_file_location('asciidoc', self.cmd)
-module = importlib.util.module_from_spec(spec)
+# Thanks to Mad Physicist for this solution, read on 2019-11-19
+# https://stackoverflow.com/questions/2601047/import-a-python-module-without-the-py-extension/43602645#43602645
+from importlib.util import spec_from_loader, module_from_spec
+from importlib.machinery import SourceFileLoader
+loader = SourceFileLoader('asciidoc', self.cmd)
+spec = spec_from_loader('asciidoc', loader)
+module = module_from_spec(spec)
spec.loader.exec_module(module)
self.asciidoc = module
except ImportError:
signature.asc
Description: PGP signature
Bug#895462: Please keep asciidoc in Debian
Hello, please keep asciidoc in Debian. With the current python3 port it will continue to work even when Python 2 is removed. I'm using asciidoc for a few (private) projects which depend on some features not yet provided by asciidoctor (e.g. proper localization with support for multiple languages and flexibility through additional config files). Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#941836: blhc: false positive for libtool relink mode?
On Sun, Oct 06, 2019 at 12:40:22PM +0200, Yves-Alexis Perez wrote:
> On Sun, 2019-10-06 at 11:47 +0200, Simon Ruderich wrote:
>> Now I'm somewhat confused. I think the issue in this case is not
>> "libtool: relink:" because I get no errors for those lines when
>> running blhc on the buildd log.
>>
>> Instead, I think the problem is the quoting of the libtool
>> command. Could you try the attached patch?
>
> It seems to work fine, thanks.
Thanks for verifying. I've pushed c4814aa ("Fix false positive in
libtool detection with quoted path", 2019-10-06) [1] with the
fix.
I've also released blhc 0.10 with the recent fixes. [2]
Regards
Simon
[1]:
https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=c4814aa2ad8a7a35e71839347b7fae2507be2ded
[2]: https://ruderich.org/simon/blhc/#_download
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
signature.asc
Description: PGP signature
Bug#941836: blhc: false positive for libtool relink mode?
On Sun, Oct 06, 2019 at 11:22:57AM +0200, Yves-Alexis Perez wrote: > Or a “real” build log from the buildd network: > https://buildd.debian.org/status/fetch.php?pkg=strongswan=amd64=5.8.0-1=1566867301=0 Thanks, that's the link I was looking for. > Here's an example: > > libtool: warning: relinking 'libstrongswan-eap-radius.la' > libtool: install: (cd /<>/src/libcharon/plugins/eap_radius; > /bin/bash "/<>/libtool" --tag CC --mode=relink gcc -rdynamic -g > -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -include /<>/config.h -module -avoid- > version -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -Wl,-O1 -o libstrongswan-eap- > radius.la -rpath /usr/lib/ipsec/plugins eap_radius_plugin.lo eap_radius.lo > eap_radius_xauth.lo eap_radius_accounting.lo eap_radius_provider.lo > eap_radius_dae.lo eap_radius_forward.lo ../../../../src/libradius/libradius.la > -inst-prefix-dir /<>/debian/tmp) > libtool: relink: gcc -shared -fPIC -DPIC .libs/eap_radius_plugin.o > .libs/eap_radius.o .libs/eap_radius_xauth.o .libs/eap_radius_accounting.o > .libs/eap_radius_provider.o .libs/eap_radius_dae.o > .libs/eap_radius_forward.o -Wl,-rpath -Wl,/usr/lib/ipsec > -L/<>/debian/tmp/usr/lib/ipsec -L/usr/lib/ipsec -lradius -g -O2 > -fstack-protector-strong -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed -Wl,- > O1 -Wl,-soname -Wl,libstrongswan-eap-radius.so -o .libs/libstrongswan-eap- > radius.so > > Libtool steps are displayed on two lines (libtool --mode=relink followed by > libtool: relink), but this is already handled fine by blhc. Now I'm somewhat confused. I think the issue in this case is not "libtool: relink:" because I get no errors for those lines when running blhc on the buildd log. Instead, I think the problem is the quoting of the libtool command. Could you try the attached patch? Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 diff --git i/bin/blhc w/bin/blhc index fba278f..d6e2690 100755 --- i/bin/blhc +++ w/bin/blhc @@ -53,7 +53,7 @@ my $cc_regex_normal = qr/ my $warning_regex = qr/^(.+?):(\d+):\d+: warning: (.+?) \[(.+?)\]$/; # Regex to catch libtool commands and not lines which show commands executed # by libtool (e.g. libtool: link: ...). -my $libtool_regex = qr/\blibtool\s.*--mode=/; +my $libtool_regex = qr/\blibtool["']?\s.*--mode=/; my $libtool_link_regex = qr/\blibtool: link: /; # List of source file extensions which require preprocessing. signature.asc Description: PGP signature
Bug#941836: blhc: false positive for libtool relink mode?
On Sun, Oct 06, 2019 at 09:47:11AM +0200, Yves-Alexis Perez wrote:
> Package: blhc
> Version: 0.09-2
> Severity: normal
>
> Hi,
>
> blhc running on salsaci for strongSwan reports failure
> (https://salsa.debian.org/debian/strongswan/-/jobs/350397/raw) at the
> blhc step because of lines like these:
>
> 8890:CPPFLAGS missing (-D_FORTIFY_SOURCE=2): /bin/bash
> "/build/strongswan-5.8.0/libtool" --tag CC --mode=relink gcc -rdynamic
> -g -O2 -fdebug-prefix-map=/build/strongswan-5.8.0=.
> -fstack-protector-strong -Wformat -Werror=format-security -include
> /build/strongswan-5.8.0/config.h -module -avoid-version -Wl,-z,relro
> -Wl,-z,now -Wl,--as-needed -Wl,-O1 -o libstrongswan-kernel-libipsec.la
> -rpath /usr/lib/ipsec/plugins kernel_libipsec_plugin.lo
> kernel_libipsec_ipsec.lo kernel_libipsec_router.lo
> ../../../../src/libipsec/libipsec.la -inst-prefix-dir
> /build/strongswan-5.8.0/debian/tmp)
>
> I have the feelink that $libtool_link_regex should cover relink as well,
> maybe with:
>
> my $libtool_link_regex = qr/\blibtool: (?:re)?link: /;
>
> which seems to mute the error here (not entirely sure it's correct
> though).
Hi,
sounds sensible. Can I get the relevant parts of the original
build log? Your updated regex won't match the line you pasted
('libtool: ' vs. '/libtool" --tag CC --mode=relink') and I want
to make sure my fix works with the original build log.
Regards
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
signature.asc
Description: PGP signature
Bug#940497: ocrmypdf: Fails with "Error: /invalidfileaccess in --file--"
Package: ocrmypdf Version: 9.0.1+dfsg-1 Severity: important Tags: patch Hello, running ocrmypdf (ocrmypdf --lang deu --deskew) fails with the following error ERROR - GPL Ghostscript RELEASE CANDIDATE 2 9.28: Setting Overprint Mode to 1 not permitted in PDF/A-2, overprint mode not set Error: /invalidfileaccess in --file-- Operand stack: --nostringval-- --nostringval-- (/usr/lib/python3/dist-packages/ocrmypdf/data/sRGB.icc) (r) Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1974 1 3 %oparray_pop 1973 1 3 %oparray_pop 1961 1 3 %oparray_pop 1817 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- Dictionary stack: --dict:736/1123(ro)(G)-- --dict:1/20(G)-- --dict:76/200(L)-- Current allocation mode is local Last OS error: Permission denied Current file position is 576 GPL Ghostscript RELEASE CANDIDATE 2 9.28: Unrecoverable error, exit code 1 ERROR - SubprocessOutputError: Ghostscript PDF/A rendering failed This is fixed by upstream commit [1], released in version 9.0.3. Please consider packaging the latest version to fix this issue. Regards Simon [1]: https://github.com/jbarlow83/OCRmyPDF/commit/17ac9d7a9a296ae3d50146fbefad5281e2851b0f -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#939632: blhc: false positives with Python cython Compiling
On Sat, Sep 07, 2019 at 08:23:53AM +0200, Picca Frédéric-Emmanuel wrote:
> Dear Maintainer,
>
> When using cythonizing .pyx files, we got this message from blhc.
>
> 718:NONVERBOSE BUILD: Compiling pyzoltan/core/carray.pyx because it changed.
>
> [snip]
Hello,
thanks for the report. Should be fixed in 5fa7a26 ("Fix false
positive in non-verbose check for cython's .pyx files",
2019-09-07) [1].
Regards
Simon
[1]
https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=5fa7a26d171b5557884db3906ec13de46ab35449
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
signature.asc
Description: PGP signature
Bug#924387: blhc complains about missing -Wformat in Fortran FFLAGS, but dpkg-buildflags does not include these
On Fri, Aug 30, 2019 at 10:48:48PM +0200, Daniel Leidert wrote:
>> Could you provide me with a full build log so I can reproduce the
>> issue?
>
> https://salsa.debian.org/debichem-team/xcrysden/-/jobs/263080
Thanks, I took the full build log from
https://salsa.debian.org/debichem-team/xcrysden/-/jobs/263075/raw
and can reproduce the issue.
The problem was that the workaround in blhc requires the build
dependencies to detect if fortran is used. I've simply removed
the checks in eaa4bec ("Fix format CFLAGS for Ada/Fortran with
some build logs", 2019-08-31) [1] and it should work now.
Regards
Simon
[1]
https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=eaa4bece3aca1798ffe5a13030cca3dfbdd4ce0c
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
signature.asc
Description: PGP signature
Bug#932213: blhc: Avoid triggering warnings for CC_FOR_BUILD compilations
On Tue, Jul 16, 2019 at 12:51:44PM -0400, Daniel Kahn Gillmor wrote: > But this is all pretty complicated and i'm not convinced that it is > worthwhile. It might make more sense for blhc to be able to detect > and skip these local helper tools. Hello Daniel, while I think it would be nice if blhc could detect local helper tools I'm not sure how to accomplish this. In theory, it could track which programs are distributed but this will be quite complicated and might hide bugs where object files are (re)used in binaries which are then shipped. Suggestions are welcome of course. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#930993: blhc: false positives with Python setuptools compile_catalog
On Mon, Jun 24, 2019 at 09:53:37AM +0100, Simon McVittie wrote:
>> 487:NONVERBOSE BUILD: compiling catalog tap/locale/ja/LC_MESSAGES/tappy.po
>> to tap/locale/ja/LC_MESSAGES/tappy.mo
>> 488:NONVERBOSE BUILD: compiling catalog tap/locale/nl/LC_MESSAGES/tappy.po
>> to tap/locale/nl/LC_MESSAGES/tappy.mo
> (etc.)
>
> I think this should be treated as a false positive: this is not a C
> compiler or similar.
Hello Simon,
sorry for the late reply. Should be fixed in 0798b6d ("Fix false
positive in non-verbose check for python setuptools", 2019-08-24)
[1].
Regards
Simon
[1]:
https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=0798b6d8fc65dd5fe2a975789dea153a96dcac89
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
signature.asc
Description: PGP signature
Bug#924387: blhc complains about missing -Wformat in Fortran FFLAGS, but dpkg-buildflags does not include these
On Tue, Mar 12, 2019 at 11:49:14AM +0100, Christoph Berg wrote: > Package: blhc > Severity: normal > > Hi, > > I've recently activated the salsa ci infrastructure for the wsjtx > package which includes some Fortran files. The blhc check complains > about missing flags: > > [snip] > > The -Wformat -Werror=format-security flags are not there because > dpkg-buildflags does not set them: > > $ dpkg-buildflags | grep ^F > FCFLAGS=-g -O2 -fdebug-prefix-map=/home/cbe/projects/afu/wsjtx=. > -fstack-protector-strong > FFLAGS=-g -O2 -fdebug-prefix-map=/home/cbe/projects/afu/wsjtx=. > -fstack-protector-strong Hello, sorry for the late reply. Could you provide me with a full build log so I can reproduce the issue? In theory blhc already handles this case properly and it works fine if I just add your line to the existing testcase "t/logs/fortran". So I guess the auto-detection of fortran breaks: At the moment it checks if the "gfortran" package is installed (via the "Filtered Build-Depends:" output). Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#900056: certspotter: Please update to latest upstream version
Package: certspotter Version: 0.8-1+b1 Severity: normal Hello, please update to the latest upstream release, currently 0.9, which removes support for now non-functional logs fixing the following error messages: certspotter: ct.startssl.com: 2018/05/22 16:40:07 Error retrieving STH from log: Get https://ct.startssl.com/ct/v1/get-sth: dial tcp 104.192.110.221:443: i/o timeout certspotter: ctlog.wosign.com: 2018/05/22 16:40:08 Error retrieving STH from log: GET https://ctlog.wosign.com/ct/v1/get-sth: 404 Not Found ( 404 Not Found 404 Not Found nginx/1.10.2 ) The changes from 0.8 to 0.9 are minimal and the package builds without any changes. $ sha512sum certspotter_0.9.orig.tar.gz fe77cc212b58bce85c80c04e06a18c33bfc211b52920c9876ba3ff4b8bfbee92468c8f3915d576229f3c54417501ff042f95e57d9e46dbc5b35085062eee67d0 certspotter_0.9.orig.tar.gz Please also consider making a backport to stretch so users can enjoy less error messages. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#899137: blhc: Reports missing flags on non-compile lines
On Sat, May 19, 2018 at 07:57:26PM +0200, Kurt Roeckx wrote:
> Package: blhc
> Version: 0.07+20170817+gita232d32-0.1
>
> https://qa.debian.org/bls/packages/o/openssl.html currently
> reports among other things:
> dpkg-buildflags-missing CPPFLAGS 3 (of 1664), CFLAGS 1 (of 1662), LDFLAGS 2
> (of 298) missing (amd64)
>
> When I download that file
> (https://buildd.debian.org/status/fetch.php?pkg=openssl=amd64=1.1.0h-3=1526644885=0),
> and run it myself, I get:
> CPPFLAGS missing (-D_FORTIFY_SOURCE=2): 0150 - 2e 4f 04 0c 0f d4 7c 07-11
> 8a 14 ae ca cc b4 53 .O|S
> LDFLAGS missing (-Wl,-z,relro): 0150 - 2e 4f 04 0c 0f d4 7c 07-11 8a 14
> ae ca cc b4 53 .O|S
> CFLAGS missing (-g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security): 0350 - 12 82 f0 da b8 82 57 4b-71 6a e1 8d 6e
> ce cc 69 ..WKqj..n..i
> LDFLAGS missing (-Wl,-z,relro): 0350 - 12 82 f0 da b8 82 57 4b-71 6a e1
> 8d 6e ce cc 69 ..WKqj..n..i
>
> Those are some debug output of the test suite, clearly nothing is
> being compiled on those lines.
Hello Kurt,
Thanks for the bug report. Fixed in 95af905 ("Don't treat
hexdumps which contain "cc" as compiler lines", 2018-05-20) [1].
The blhc maintainer seems to be busy so it may take a while to
get this into Debian. If you (or any other DD) have some time,
you could package the latest Git version which contains multiple
fixes and closes a few Debian bugs.
Regards
Simon
[1]
https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=95af90589fc9239baedfb30560fb69eff2c669d7
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
signature.asc
Description: PGP signature
Bug#898333: blhc: Reports missing -D_FORTIFY_SOURCE=2 for compilation of assembly files
On Thu, May 10, 2018 at 07:32:54PM +0900, Mike Hommey wrote: > [snip] > > CPPFLAGS missing (-D_FORTIFY_SOURCE=2): /usr/bin/gcc -std=gnu99 -o > xptcinvoke_asm_x86_64_unix.o -DNDEBUG=1 -DTRIMMED=1 > -DSTATIC_EXPORTABLE_JS_API -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API > -DIMPL_LIBXUL -g -fPIC -Wa,--noexecstack -include > /<>/build-browser/mozilla-config.h -DMOZILLA_CLIENT -g > -I/<>/xpcom/reflect/xptcall > -I/<>/xpcom/reflect/xptinfo -c > /<>/xpcom/reflect/xptcall/md/unix/xptcinvoke_asm_x86_64_unix.S > > [snip] > > Sure, -F_FORTIFY_SOURCE=2 *is* missing on those command lines, but it's > also, afaik, irrelevant when compiling assembly files (.S), even if they > are preprocessed. Hey Mike, True, fortify source will very likely not be used by assembly files so this looks like a false positive. However blhc doesn't treat fortify source specially and tracks the use of all CPPFLAGS. As .S files are preprocessed it expects all CPPFLAGS to be present. So this report from blhc is valid (even though it might be confusing). Adding CPPFLAGS is the correct fix for this issue. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#898332: blhc: Reports preprocessor flags missing when they were disabled but re-enabled
On Thu, May 10, 2018 at 07:28:08PM +0900, Mike Hommey wrote:
> [snip]
>
> As you can see, -D_FORTIFY_SOURCE=2 is actually *not* missing. It's
> enabled, but then disabled, which I guess why blhc is complaining, but
> it's then re-enabled (and re-disabled, and re-enabled again)
Hey Mike,
Thanks for the bug report, fixed in 14b61d4 ("Detect restore of
-D_FORTIFY_SOURCE=2", 2018-05-10) [1].
Regards
Simon
[1]:
https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=14b61d421e2479318cb2971acc1c94812f5a8ac1
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
signature.asc
Description: PGP signature
Bug#872413: kpatch: Please package new upstream version
On Thu, Apr 12, 2018 at 05:03:42PM +0200, Vincent Bernat wrote:
> Hi!
>
> As the package is not currently usable with our kernel, or even the
> one in stable, I am bumping the severity. Since you already worked a
> lot on this, would you be interested to prepare an upload for 0.5.0? If
> yes, we could sort out how to organize that.
Hello,
Thanks for your initiative. Patch to update to 0.5.0 (as diff
from the current version in Debian Sid) is attached. It's based
on the upstream kpatch tarball from github with the following
sha512 checksum:
d7e45a4395a8c7632187ca5c8b837bad0d7583f66ce5f5d2b8f1acabf9ff2539d038a16986f9846818183f5c3268a613580a98ad72f3766e286e6273d57ddc78
kpatch_0.5.0.orig.tar.gz
Regards
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
diff -u -r kpatch-0.3.2/debian/changelog kpatch-0.5.0/debian/changelog
--- kpatch-0.3.2/debian/changelog 2017-04-01 21:33:40.0 +0200
+++ kpatch-0.5.0/debian/changelog 2018-04-13 15:56:07.615948149 +0200
@@ -1,3 +1,9 @@
+kpatch (0.5.0-0.1) unstable; urgency=medium
+
+ * Package 0.5.0.
+
+ -- Simon Ruderich <si...@ruderich.org> Fri, 13 Apr 2018 15:55:45 +0200
+
kpatch (0.3.2-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff -u -r kpatch-0.3.2/debian/control kpatch-0.5.0/debian/control
--- kpatch-0.3.2/debian/control 2016-06-27 21:03:09.0 +0200
+++ kpatch-0.5.0/debian/control 2017-10-16 23:20:59.660634108 +0200
@@ -2,7 +2,7 @@
Section: kernel
Priority: optional
Maintainer: Chris J Arges <chris.j.ar...@canonical.com>
-Build-Depends: debhelper (>= 9), libelf-dev, dkms
+Build-Depends: debhelper (>= 9), libelf-dev, dkms, shellcheck
Standards-Version: 3.9.8
Homepage: http://github.com/dynup/kpatch
#Vcs-Git: git://anonscm.debian.org/collab-maint/kpatch.git
@@ -10,8 +10,7 @@
Package: kpatch
Architecture: linux-amd64
-Depends: ${shlibs:Depends}, ${misc:Depends}, kpatch-dkms,
- linux-headers-amd64 | linux-headers-generic
+Depends: ${shlibs:Depends}, ${misc:Depends}, binutils
Description: Runtime tools for Kpatch
kpatch is a Linux dynamic kernel patching tool which allows you to patch a
running kernel without rebooting or restarting any processes. It enables
@@ -22,7 +21,8 @@
Package: kpatch-dkms
Architecture: linux-amd64
-Depends: ${shlibs:Depends}, ${misc:Depends}, dkms
+Depends: ${shlibs:Depends}, ${misc:Depends}, dkms,
+ linux-headers-amd64 | linux-headers-generic
Description: DKMS module for Kpatch
This package contains the Kpatch module built with DKMS. It installs the source
and makefiles into the appropriate locations in order to handle various kernel
Only in kpatch-0.3.2/debian/patches: create-diff-object-fix-WARN-_ONCE-detection-on-newer.patch
Only in kpatch-0.3.2/debian/patches: kmod-core-use-save_stack_trace_tsk-backport.patch
diff -u -r kpatch-0.3.2/debian/patches/kpatch-build-adjust-dirs.patch kpatch-0.5.0/debian/patches/kpatch-build-adjust-dirs.patch
--- kpatch-0.3.2/debian/patches/kpatch-build-adjust-dirs.patch 2016-02-18 17:46:39.0 +0100
+++ kpatch-0.5.0/debian/patches/kpatch-build-adjust-dirs.patch 2018-04-13 16:07:01.934186446 +0200
@@ -3,26 +3,37 @@
paths to adjust for this. In addition the debian packaging uses /usr/lib
instead of /usr/libexec for internal binaries.
Author: Chris J Arges <chris.j.ar...@canonical.com>
-Last-Update: 2016-01-08
+Last-Update: 2018-04-14
a/kpatch-build/kpatch-build
-+++ b/kpatch-build/kpatch-build
-@@ -99,14 +99,14 @@
- DATADIR="$(readlink -f $SCRIPTDIR/../kmod)"
+Index: kpatch-0.5.0/kpatch-build/kpatch-build
+===
+--- kpatch-0.5.0.orig/kpatch-build/kpatch-build
kpatch-0.5.0/kpatch-build/kpatch-build
+@@ -159,9 +159,9 @@ find_dirs() {
+ TOOLSDIR="$SCRIPTDIR"
+ DATADIR="$(readlink -f "$SCRIPTDIR/../kmod")"
+ PLUGINDIR="$(readlink -f "$SCRIPTDIR/gcc-plugins")"
+- elif [[ -e "$SCRIPTDIR/../libexec/kpatch/create-diff-object" ]]; then
++ elif [[ -e "$SCRIPTDIR/../lib/kpatch/create-diff-object" ]]; then
+ # installation path
+- TOOLSDIR="$(readlink -f "$SCRIPTDIR/../libexec/kpatch")"
++ TOOLSDIR="$(readlink -f "$SCRIPTDIR/../lib/kpatch")"
+ DATADIR="$(readlink -f "$SCRIPTDIR/../share/kpatch")"
+ PLUGINDIR="$TOOLSDIR"
+ else
+@@ -174,12 +174,12 @@ find_core_symvers() {
+ if [[ -e "$SCRIPTDIR/create-diff-object" ]]; then
+ # git repo
SYMVERSFILE="$DATADIR/core/Module.symvers"
- return
- elif [[ -e "$SCRIPTDIR/../libexec/kpatch/create-diff-object" ]]; then
+ elif [[ -e "$SCRIPTDIR/../lib/kpatch/create-diff-object" ]]; then
# installation path
-- TOOLSDIR="$(readlink -f $SCRIPTDIR/../libexec/kpatch)"
-+ TOOLSDIR="$(readlink -f $SCRIPTDIR/../lib/kpatch)&quo
Bug#895417: libseccomp: New upstream release 2.3.3
Source: libseccomp
Version: 2.3.1-2.1
Severity: normal
Tags: patch
Hello,
please package the new upstream version 2.3.3 which adds support
for the statx syscall (which is already actively used by libqt5)
among others; this should also close #893722.
Patch with the required changes (only unfuzzing of the parisc
patch) is attached.
Regards
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
diff -u -r libseccomp-2.3.1/debian/changelog libseccomp-2.3.3/debian/changelog
--- libseccomp-2.3.1/debian/changelog 2016-11-17 10:16:44.0 +0100
+++ libseccomp-2.3.3/debian/changelog 2018-04-11 12:09:58.258096960 +0200
@@ -1,3 +1,10 @@
+libseccomp (2.3.3-0.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * New upstream release.
+
+ -- Simon Ruderich <si...@ruderich.org> Wed, 11 Apr 2018 12:09:39 +0200
+
libseccomp (2.3.1-2.1) unstable; urgency=medium
[ Martin Pitt ]
diff -u -r libseccomp-2.3.1/debian/patches/28-parisc_support.patch libseccomp-2.3.3/debian/patches/28-parisc_support.patch
--- libseccomp-2.3.1/debian/patches/28-parisc_support.patch 2016-11-17 10:16:44.0 +0100
+++ libseccomp-2.3.3/debian/patches/28-parisc_support.patch 2018-04-11 12:13:17.451686723 +0200
@@ -65,11 +65,11 @@
create mode 100644 src/arch-parisc.h
create mode 100644 src/arch-parisc64.c
-Index: libseccomp/include/seccomp.h.in
+Index: libseccomp-2.3.3/include/seccomp.h.in
===
libseccomp.orig/include/seccomp.h.in 2016-05-28 19:57:02.050592727 +0200
-+++ libseccomp/include/seccomp.h.in 2016-05-28 19:57:02.038592653 +0200
-@@ -185,6 +185,12 @@
+--- libseccomp-2.3.3.orig/include/seccomp.h.in
libseccomp-2.3.3/include/seccomp.h.in
+@@ -186,6 +186,12 @@ struct scmp_arg_cmp {
#define SCMP_ARCH_S390X AUDIT_ARCH_S390X
/**
@@ -82,11 +82,11 @@
* Convert a syscall name into the associated syscall number
* @param x the syscall name
*/
-Index: libseccomp/src/Makefile.am
+Index: libseccomp-2.3.3/src/Makefile.am
===
libseccomp.orig/src/Makefile.am 2016-05-28 19:57:02.050592727 +0200
-+++ libseccomp/src/Makefile.am 2016-05-28 19:57:02.038592653 +0200
-@@ -35,6 +35,8 @@
+--- libseccomp-2.3.3.orig/src/Makefile.am
libseccomp-2.3.3/src/Makefile.am
+@@ -35,6 +35,8 @@ SOURCES_ALL = \
arch-mips.h arch-mips.c arch-mips-syscalls.c \
arch-mips64.h arch-mips64.c arch-mips64-syscalls.c \
arch-mips64n32.h arch-mips64n32.c arch-mips64n32-syscalls.c \
@@ -95,10 +95,10 @@
arch-ppc.h arch-ppc.c arch-ppc-syscalls.c \
arch-ppc64.h arch-ppc64.c arch-ppc64-syscalls.c \
arch-s390.h arch-s390.c arch-s390-syscalls.c \
-Index: libseccomp/src/arch-parisc-syscalls.c
+Index: libseccomp-2.3.3/src/arch-parisc-syscalls.c
===
/dev/null 1970-01-01 00:00:00.0 +
-+++ libseccomp/src/arch-parisc-syscalls.c 2016-05-28 19:57:02.042592678 +0200
+--- /dev/null
libseccomp-2.3.3/src/arch-parisc-syscalls.c
@@ -0,0 +1,499 @@
+/*
+ * Copyright (c) 2016 Helge Deller <del...@gmx.de>
@@ -599,10 +599,10 @@
+ /* XXX - no safety checks here */
+ return parisc_syscall_table[spot].name;
+}
-Index: libseccomp/src/arch-parisc.c
+Index: libseccomp-2.3.3/src/arch-parisc.c
===
/dev/null 1970-01-01 00:00:00.0 +
-+++ libseccomp/src/arch-parisc.c 2016-05-28 19:57:02.042592678 +0200
+--- /dev/null
libseccomp-2.3.3/src/arch-parisc.c
@@ -0,0 +1,22 @@
+/*
+ * Copyright (c) 2016 Helge Deller <del...@gmx.de>
@@ -626,10 +626,10 @@
+ .syscall_rewrite = NULL,
+ .rule_add = NULL,
+};
-Index: libseccomp/src/arch-parisc.h
+Index: libseccomp-2.3.3/src/arch-parisc.h
===
/dev/null 1970-01-01 00:00:00.0 +
-+++ libseccomp/src/arch-parisc.h 2016-05-28 19:57:02.042592678 +0200
+--- /dev/null
libseccomp-2.3.3/src/arch-parisc.h
@@ -0,0 +1,38 @@
+/**
+ * Enhanced Seccomp PARISC Specific Code
@@ -669,10 +669,10 @@
+const char *parisc_syscall_iterate_name(unsigned int spot);
+
+#endif
-Index: libseccomp/src/arch-parisc64.c
+Index: libseccomp-2.3.3/src/arch-parisc64.c
===
/dev/null 1970-01-01 00:00:00.0 +
-+++ libseccomp/src/arch-parisc64.c 2016-05-28 19:57:02.042592678 +0200
+--- /dev/null
libseccomp-2.3.3/src/arch-parisc64.c
@@ -0,0 +1,22 @@
+/*
+ * Copyright (c) 2016 Helge Deller <del...@gmx.de>
@@ -696,10 +696,10 @@
+ .syscall_rewrite = NULL,
+ .rule_add = NULL,
+};
-Index: libseccomp/src/arch-syscall-check.c
+Index: libseccomp-2.3.3/src/arch-syscall-check.c
===
libseccomp.orig/src/arch-syscall-check.c 2016-05-28
Bug#712485:
On Fri, Feb 09, 2018 at 12:14:40PM +0100, Simon Ruderich wrote: > On Fri, Feb 09, 2018 at 09:07:06AM +, Nico Schlömer wrote: >> Perhaps it's useful to report which are the offending lines in the build >> log. For Trilinos [1], for example, a hidden flags are reported, but I have >> no idea why. Can you help me out? > > Hello, > > Running blhc on the build log lists the offending lines: > > NONVERBOSE BUILD: [ 76%] Building CXX object > packages/nox/src/CMakeFiles/trilinos_nox.dir/NOX_Abstract_Vector.C.o > NONVERBOSE BUILD: [ 97%] Building CXX object > packages/stokhos/test/UnitTest/CMakeFiles/Stokhos_TpetraCrsMatrixMPVectorUnitTest_Serial.dir/Stokhos_TpetraCrsMatrixMPVectorUnitTest_Serial.cpp.o > > I'm not sure if the output can/should be added to the > lintian/build log parser as it can be quite big and I don't know > how the architecture handles custom output. > > CCing Bernhard who I think is managing the build log parser. On Fri, Mar 02, 2018 at 09:42:37AM +0100, Simon Ruderich wrote: > Hi Nico, > > Not sure how I missed this mail, sorry for that. I've just > released blhc 0.08 which contains a --line-numbers option > (suggested by Stefan Pöschel). Ah, didn't miss it just overlooked the mail in my mailbox and then misread your original mail, sorry for the confusion. Still waiting for Bernhard's reply. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#712485:
On Fri, Feb 09, 2018 at 09:07:06AM +, Nico Schlömer wrote: > Perhaps it's useful to report which are the offending lines in the build > log. For Trilinos [1], for example, a hidden flags are reported, but I have > no idea why. Can you help me out? Hi Nico, Not sure how I missed this mail, sorry for that. I've just released blhc 0.08 which contains a --line-numbers option (suggested by Stefan Pöschel). Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#712485:
On Fri, Feb 09, 2018 at 09:07:06AM +, Nico Schlömer wrote: > Perhaps it's useful to report which are the offending lines in the build > log. For Trilinos [1], for example, a hidden flags are reported, but I have > no idea why. Can you help me out? Hello, Running blhc on the build log lists the offending lines: NONVERBOSE BUILD: [ 76%] Building CXX object packages/nox/src/CMakeFiles/trilinos_nox.dir/NOX_Abstract_Vector.C.o NONVERBOSE BUILD: [ 97%] Building CXX object packages/stokhos/test/UnitTest/CMakeFiles/Stokhos_TpetraCrsMatrixMPVectorUnitTest_Serial.dir/Stokhos_TpetraCrsMatrixMPVectorUnitTest_Serial.cpp.o I'm not sure if the output can/should be added to the lintian/build log parser as it can be quite big and I don't know how the architecture handles custom output. CCing Bernhard who I think is managing the build log parser. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#877177: postfix: Configuration file /lib/systemd/system/postfix@.service is marked executable.
Package: postfix Version: 3.2.3-1 Severity: normal Hello, On upgrade to this version journald warned my about: Configuration file /lib/systemd/system/postfix@.service is marked executable. Please remove executable permission bits. Proceeding anyway. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#845339: blhc: checks for PIE can be incompatible with recent dpkg versions
On Tue, Sep 05, 2017 at 12:37:01PM -0300, Eriberto wrote: >> blhc doesn't check for bindnow (and PIE) per default unless you >> use the --bindnow (or --all) option. I get the same output for >> the following commands (which report the missing -Wl,-z,now): >> >> blhc --bindnow nload_0.7.4-2_amd64.build >> blhc --bindnow --debian nload_0.7.4-2_amd64.build > > Hum... I can't see anything. These commands report nothing for me. Now I'm really confused. Which version of blhc are you using? Here's again what I did and the output I get (running in the blhc repository): $ git describe 0.07-10-ga232d32 $ shasum bin/blhc 9abe92519031dbf88ebde59f53b4b7eb8943f1e0 bin/blhc $ shasum nload_0.7.4-2_amd64.build 866d39fa12769a6c4f694aac890b893b4c9cfce7 nload_0.7.4-2_amd64.build $ ./bin/blhc --bindnow nload_0.7.4-2_amd64.build LDFLAGS missing (-Wl,-z,now): g++ -g -O2 -fdebug-prefix-map=/PKGS/nload/nload-0.7.4=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wl,-z,relro -s -o nload device.o devreader.o devreaderfactory.o form_field.o graph.o main.o opt_window.o screen.o setting.o settingfilter.o settingstore.o statistics.o stringutils.o traffic_window.o window.o devreader-linux.o devreader-linux-proc.o devreader-linux-sys.o -lform -lncurses $ ./bin/blhc --bindnow --debian nload_0.7.4-2_amd64.build LDFLAGS missing (-Wl,-z,now): g++ -g -O2 -fdebug-prefix-map=/PKGS/nload/nload-0.7.4=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wl,-z,relro -s -o nload device.o devreader.o devreaderfactory.o form_field.o graph.o main.o opt_window.o screen.o setting.o settingfilter.o settingstore.o statistics.o stringutils.o traffic_window.o window.o devreader-linux.o devreader-linux-proc.o devreader-linux-sys.o -lform -lncurses >> However with the --all option you are required to also specify >> the --arch option to ignore "missing" PIE flags (or use a build >> log which reports the architecture) as PIE is only injected by >> gcc on certain architectures: >> >> blhc --arch=amd64 --all --debian nload_0.7.4-2_amd64.build > > Can you add these information to manpage and add a new example? Added in [1]. Suggestions (as patches) welcome. Regards Simon [1] https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=8f13ff5cfeb4cd6f4102cd0448a9f5dfa089491e -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#845339: blhc: checks for PIE can be incompatible with recent dpkg versions
On Thu, Aug 17, 2017 at 10:35:01AM -0300, Eriberto Mota wrote: > Hi Simon, > > Thanks for your reply. I did a test over nload package and I think > that blhc --debian is ignoring all lines with "PIE". I removed the > option line from debian/rules file (export DEB_BUILD_MAINT_OPTIONS = > hardening=+all). Without this line, was hoping to see it: > > LDFLAGS missing (-Wl,-z,now): g++ -g -O2 > -fdebug-prefix-map=/PKGS/nload/nload-0.7.4=. -fstack-protector-strong > -Wformat -Werror=format-security -Wall -Wl,-z,relro -s -o nload > device.o devreader.o devreaderfactory.o form_field.o graph.o main.o > opt_window.o screen.o setting.o settingfilter.o settingstore.o > statistics.o stringutils.o traffic_window.o window.o > devreader-linux.o devreader-linux-proc.o devreader-linux-sys.o > -lform -lncurses > > However, I saw nothing with --debian. Hello Eriberto, Sorry again for the late reply. blhc doesn't check for bindnow (and PIE) per default unless you use the --bindnow (or --all) option. I get the same output for the following commands (which report the missing -Wl,-z,now): blhc --bindnow nload_0.7.4-2_amd64.build blhc --bindnow --debian nload_0.7.4-2_amd64.build However with the --all option you are required to also specify the --arch option to ignore "missing" PIE flags (or use a build log which reports the architecture) as PIE is only injected by gcc on certain architectures: blhc --arch=amd64 --all --debian nload_0.7.4-2_amd64.build Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#873314: golang-github-lib-pq-dev: Please package new snapshot
Package: golang-github-lib-pq-dev Version: 0.0~git20151007.0.ffe986a-1 Severity: wishlist The current version in Debian is quite old and misses important features like Arrays. Please consider packaging the latest Git version. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#873066: anki: Shortcuts not working since pyqt5 5.7+dfsg-6
Package: anki Version: 2.1.0+dfsg~a12-0.1 Severity: normal Hello, Since the latest pyqt5 update to 5.7+dfsg-6 the shortcuts (like pressing 1, 2, 3 to select Again, Hard, Good) have no effect. Only selecting the currently highlighted element with space continues to work. Regards Simon -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Versions of packages anki depends on: ii libjs-jquery3.1.1-2 ii libjs-jquery-flot 0.8.3+dfsg-1 ii libjs-jquery-ui 1.12.1+dfsg-5 ii python3 3.5.3-3 ii python3-bs4 4.6.0-1 ii python3-httplib20.9.2+dfsg-1 ii python3-pyaudio 0.2.11-1+b1 ii python3-pyqt5 5.7+dfsg-6+b1 ii python3-pyqt5.qtwebchannel 5.7+dfsg-6+b1 ii python3-pyqt5.qtwebengine 5.7+dfsg-6+b1 ii python3-requests2.18.1-1 ii python3-send2trash 1.3.0-3 -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#872892: pyqt5: FTBFS with Qt 5.9
Source: pyqt5
Version: 5.7+dfsg-5
Severity: important
Tags: patch
Hello,
With the latest update to Qt 5.9 pyqt5 fails to build from source
blocking the update of many Qt packages on my system.
The attached two patches seem to fix the build, but I think the
latest pyqt5 upstream version should be tried first (but I
haven't checked if it added support for Qt 5.9). qt58.patch was
authored by Heiko Becker [1].
Regards
Simon
[1]: https://www.riverbankcomputing.com/pipermail/pyqt/2017-January/038665.html
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
Index: pyqt5-5.7+dfsg/configure.py
===
--- pyqt5-5.7+dfsg.orig/configure.py
+++ pyqt5-5.7+dfsg/configure.py
@@ -2666,12 +2666,6 @@ def check_license(target_config, license
(ltype, PYQT_VERSION_STR, lname, sys.version.split()[0],
sys.platform))
-# Common checks.
-if introspecting and target_config.qt_licensee not in OPEN_SOURCE_LICENSEES and ltype == 'GPL':
-error(
-"This version of PyQt5 and the commercial version of Qt have "
-"incompatible licenses.")
-
# Confirm the license if not already done.
if not license_confirmed:
loptions = """
Index: pyqt5-5.7+dfsg/sip/QtCore/qnamespace.sip
===
--- pyqt5-5.7+dfsg.orig/sip/QtCore/qnamespace.sip
+++ pyqt5-5.7+dfsg/sip/QtCore/qnamespace.sip
@@ -209,8 +209,6 @@ namespace Qt
WindowContextHelpButtonHint,
WindowShadeButtonHint,
WindowStaysOnTopHint,
-WindowOkButtonHint,
-WindowCancelButtonHint,
WindowStaysOnBottomHint,
WindowCloseButtonHint,
MacWindowToolBarButtonHint,
@@ -232,6 +230,10 @@ namespace Qt
%If (Qt_5_5_0 -)
MaximizeUsingFullscreenGeometryHint,
%End
+%If (- Qt_5_8_0)
+WindowOkButtonHint,
+WindowCancelButtonHint,
+%End
};
typedef QFlags WindowFlags;
Index: pyqt5-5.7+dfsg/sip/QtCore/QtCoremod.sip
===
--- pyqt5-5.7+dfsg.orig/sip/QtCore/QtCoremod.sip
+++ pyqt5-5.7+dfsg/sip/QtCore/QtCoremod.sip
@@ -22,7 +22,7 @@
%Module(name=PyQt5.QtCore, call_super_init=True, default_VirtualErrorHandler=PyQt5, keyword_arguments="Optional", version=1)
-%Timeline {Qt_5_0_0 Qt_5_0_1 Qt_5_0_2 Qt_5_1_0 Qt_5_1_1 Qt_5_2_0 Qt_5_2_1 Qt_5_3_0 Qt_5_3_1 Qt_5_3_2 Qt_5_4_0 Qt_5_4_1 Qt_5_4_2 Qt_5_5_0 Qt_5_5_1 Qt_5_6_0 Qt_5_6_1 Qt_5_7_0}
+%Timeline {Qt_5_0_0 Qt_5_0_1 Qt_5_0_2 Qt_5_1_0 Qt_5_1_1 Qt_5_2_0 Qt_5_2_1 Qt_5_3_0 Qt_5_3_1 Qt_5_3_2 Qt_5_4_0 Qt_5_4_1 Qt_5_4_2 Qt_5_5_0 Qt_5_5_1 Qt_5_6_0 Qt_5_6_1 Qt_5_7_0 Qt_5_8_0}
%Platforms {WS_X11 WS_WIN WS_MACX}
signature.asc
Description: PGP signature
Bug#872413: kpatch: Please package new upstream version
On Thu, Aug 17, 2017 at 10:21:26AM +0200, Simon Ruderich wrote: > - Add patch to fix uname -p (which always returns unknown on my > systems); I think this should be upstreamed. > fix-uname-p.patch > - Add patch to respect CPPFLAGS. Should be upstreamed as well. > respect-cppflags.patch As I was already submitting other patches, I've submitted those two patches to upstream as well so you don't have to look into upstreaming them. They should be merged soon. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#845339: blhc: checks for PIE can be incompatible with recent dpkg versions
On Mon, Jul 24, 2017 at 03:50:34PM -0300, Eriberto wrote: > I think that you can create a new option '--debian' to ignore PIE. > What you think about this? I'm not totally satisfied with a new option (would be nice if it could happen by default but still prevent false negatives) but can't think of a better way. It's now implemented in a232d3 [1]. Regards Simon [1]: https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=a232d32f22387fdaf393ee3fa51c0ae9922cf824 -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#872413: kpatch: Please package new upstream version
Package: kpatch
Version: 0.3.2-3.1
Severity: normal
Tags: patch
Hello,
The version of kpatch in Sid is quite old and doesn't work with
the current kernel. Please consider updating to the latest
upstream version. However it seems that 0.4.0 (latest release) is
not recent enough, so consider using the latest Git version (e.g.
4b2f20e) which works fine me.
The attached patch performs the update to 0.4.0+git4b2f20e and
works fine here (Sid and Stretch). It also adds a few minor
changes to better suit current upstream:
- Upstream uses the kernel's LIVEPATCH per default and only falls
back to its own kpatch.ko module if LIVEPATCH is not available.
As LIVEPATCH is supported since Stretch, my patch removes the
dependency on kpatch-dkms as kpatch works fine without it and
users of older kernels can install it manully if necessary. Not
depending on dkms (and thus a compiler) is a nice feature.
- Remove patches which are no longer required:
create-diff-object-fix-WARN-_ONCE-detection-on-newer.patch
kmod-core-use-save_stack_trace_tsk-backport.patch
- Update existing patches to apply.
- Add patch to fix uname -p (which always returns unknown on my
systems); I think this should be upstreamed.
fix-uname-p.patch
- Add patch to respect CPPFLAGS. Should be upstreamed as well.
respect-cppflags.patch
- Updates post-dkms.sh which was failing for me. It builds and
installs fine, but I didn't test it thoroughly and the comment
from the other bug still applies I think. Maybe the -dkms part
should be removed completely as upstream is switching to
LIVEPATCH (and will drop kpatch.ko in the future).
Please also consider making a backport for Stretch (package can
be backported without any issues) as the kpatch version in
Stretch doesn't work with the kernel in Stretch making it rather
useless. The Git version works fine with the Stretch kernel.
Regards
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
diff -u -N -r kpatch-0.3.2/debian/control kpatch-0.4.0+git4b2f20e/debian/control
--- kpatch-0.3.2/debian/control 2016-06-27 21:03:09.0 +0200
+++ kpatch-0.4.0+git4b2f20e/debian/control 2017-08-14 12:07:25.497788719
+0200
@@ -10,8 +10,7 @@
Package: kpatch
Architecture: linux-amd64
-Depends: ${shlibs:Depends}, ${misc:Depends}, kpatch-dkms,
- linux-headers-amd64 | linux-headers-generic
+Depends: ${shlibs:Depends}, ${misc:Depends}, binutils
Description: Runtime tools for Kpatch
kpatch is a Linux dynamic kernel patching tool which allows you to patch a
running kernel without rebooting or restarting any processes. It enables
@@ -22,7 +21,8 @@
Package: kpatch-dkms
Architecture: linux-amd64
-Depends: ${shlibs:Depends}, ${misc:Depends}, dkms
+Depends: ${shlibs:Depends}, ${misc:Depends}, dkms,
+ linux-headers-amd64 | linux-headers-generic
Description: DKMS module for Kpatch
This package contains the Kpatch module built with DKMS. It installs the
source
and makefiles into the appropriate locations in order to handle various kernel
diff -u -N -r kpatch-0.3.2/debian/patches/fix-uname-p.patch
kpatch-0.4.0+git4b2f20e/debian/patches/fix-uname-p.patch
--- kpatch-0.3.2/debian/patches/fix-uname-p.patch 1970-01-01
01:00:00.0 +0100
+++ kpatch-0.4.0+git4b2f20e/debian/patches/fix-uname-p.patch2017-08-12
12:43:07.884688093 +0200
@@ -0,0 +1,18 @@
+Description: detect architecture properly
+ uname -p returns unknown for unknown reasons. uname -m seems to work
+Author: Simon Ruderich <si...@ruderich.org>
+Last-Update: 2017-08-11
+
+Index: kpatch-0.4.0.g4b2f20e/Makefile.inc
+===
+--- kpatch-0.4.0.g4b2f20e.orig/Makefile.inc
kpatch-0.4.0.g4b2f20e/Makefile.inc
+@@ -3,7 +3,7 @@ CC= gcc
+
+ INSTALL = /usr/bin/install
+
+-ARCH = $(shell uname -p)
++ARCH = $(shell uname -m)
+
+ PREFIX?= /usr/local
+ LIBDIR?= lib
diff -u -N -r kpatch-0.3.2/debian/patches/kpatch-build-adjust-dirs.patch
kpatch-0.4.0+git4b2f20e/debian/patches/kpatch-build-adjust-dirs.patch
--- kpatch-0.3.2/debian/patches/kpatch-build-adjust-dirs.patch 2016-02-18
17:46:39.0 +0100
+++ kpatch-0.4.0+git4b2f20e/debian/patches/kpatch-build-adjust-dirs.patch
2017-08-11 23:32:54.551552778 +0200
@@ -3,26 +3,37 @@
paths to adjust for this. In addition the debian packaging uses /usr/lib
instead of /usr/libexec for internal binaries.
Author: Chris J Arges <chris.j.ar...@canonical.com>
-Last-Update: 2016-01-08
+Last-Update: 2017-08-11
a/kpatch-build/kpatch-build
-+++ b/kpatch-build/kpatch-build
-@@ -99,14 +99,14 @@
+Index: kpatch-0.4.0.g4b2f20e/kpatch-build/kpatch-build
+===
+--- kpatch-0.4.0.g4b2f20e.orig/kpatch-build/kpatch-build
kpatch-0.4.0.g4b2f20e/kpatch-build/kpatch-build
+@@ -121,9 +121,9 @@ find_dirs() {
+ # git repo
+ TOOLSDIR
Bug#845339: blhc: checks for PIE can be incompatible with recent dpkg versions
On Tue, Nov 22, 2016 at 02:13:01PM -0200, Joao Eriberto Mota Filho wrote: > Hi, > > The blhc --all is saying about PIE absence in some packages. However, the > current dpkg version changed the usage policy for PIE. Hello, Sorry for the (really) late reply. This should be partially fixed in 290a8e [1] but only for --buildd mode. This also fixes a separate bug where missing PIE flags are reported if any compiler command uses PIE even though GCC would still use PIE. However I'm not sure how --all for a "normal" log should behave. The requested flags are clearly not present and blhc can't really know that they are applied by the GCC in the background (on the buildd's that true, but maybe not in other situations). What do you think? Regards Simon [1]: https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=290a8e3484c700ebb91c3460820310e03ca38cb2 -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#853265: blhc: false positives - mpicc frontend to gcc reported as I no-compiler-commands
On Mon, Jan 30, 2017 at 10:30:04PM +0100, Boud Roukema wrote: > Package: blhc > Version: 0.07+20161116+gitbf41976 > Severity: normal > > Dear Maintainer, > > SUMMARY: On https://qa.debian.org/bls/packages/m/mpgrafic.html, > blhc, which is presumably the version of blhc presently in sid, i.e. > blhc-0.07+20161116+gitbf41976, incorrectly labels builds of mpgrafic > as "I no-compiler-commands", although mpgrafic does *both* fortran and C > compilation using frontends to gcc. > > [snip] > > While the configure order of checking for gcc and mpicc might not, in > general, give lines that are this close to one another, maybe the whole > `configure' section of the build log could be searched to see if both > the GNU C compiler and mpicc are configured. In that case, the usual > checks for absence of hardening options can be made later in the perl > script, where "mpicc" is the name of the compiler. Hello, Thank you for the detailed bug report and sorry for the late reply, I totally missed this one. It was reported separately per private mail and should be fixed (except for fortran, see below) in bc6e92 [1]. I've followed your suggestion, just slightly modified: mpicc/mpicxx are generally accepted as valid compilers (this is simpler due to the internal matching of compiler lines which is static). I tested it with your example build logs and all report no errors after the fix. > COMMENT: I'm not sure if any hardening options are valid and > recommended for gfortran - which is a fortran front end to gcc. Following the output of dpkg-buildflags it doesn't support format flags, but stack protector is supported. I've added support for gfortran (that part never worked properly) and mpifort in cda2e04 [2]. Regards Simon [1]: https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=bc6e920d8047a414012dd7f7dc152916d0670427 [2]: https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=cda2e04237c0657e09d248b7f33c6ad0dc56612e -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#810316: Allow easy use of /etc/resolv.onf
On Sun, Oct 30, 2016 at 11:00:06PM +0100, Joerg Dorchain wrote: > [snip] > > Is there a chance to build a debian package --without-unbound, > using /etc/resolv then, which can point to a locally running > unbound for those people wanting/needing a fast resolver only, > even it is it slightly more overhead than an integreated > library? > > In the current situation, I am the one with the corner case that > has problems and needs workarounds, while IMHO the average user > would not really care about the difference. Coomercial grade use > of opendkim IMHO also implies a well-thought resolver setup, > where I see full-blown unbound (i.e. including the daemon > process) commonly. Hello, I second this request. I have a very similar issue where I want to force opendkim to use my local resolver as configured in /etc/resolv.conf and I except the software to respect that choice by reading resolv.conf. Please remove the --with-unbound which fixed this issue for me. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#863891: /usr/lib/xorg/Xorg.wrap: Only console users are allowed to run the X server
On Thu, Jun 01, 2017 at 12:01:23PM -0400, Brian Minton wrote: > When I check the log, I see an error about console users: > bminton.is-a-geek.net:~/download$ cat ~/.xpra/\:42.log > /usr/lib/xorg/Xorg.wrap: Only console users are allowed to run the X server > 2017-06-01 11:57:26,652 > 2017-06-01 11:57:26,653 Xvfb command has terminated! xpra cannot continue > 2017-06-01 11:57:26,653 if the display is already running, try a different > one, > 2017-06-01 11:57:26,653 or use the --use-display flag > 2017-06-01 11:57:26,653 Hello, A simple workaround is to modify PATH to prefer the non-setuid binary: PATH="/usr/lib/xorg:$PATH" xpra ... Or modify /etc/xpra/conf.d/55_server_x11.conf: xvfb = /usr/lib/xorg/Xorg ... The problem is the auto-detection during build-time which can't find the proper path as Xorg is not installed in the build chroot during installation. Attached is a patch which adapts the path during build-time. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 Description: Fix path to Xorg binary in /etc/xpra/conf.d/55_server_x11.conf We need the (absolute) path to the non-setuid binary and not to a possibly installed setuid-wrapper (which requires root or login on a tty). Auto-dection fails as Xorg is not installed in the build environment. . As the Xorg setuid wrapper is Debian specific (and might be removed in the future) there's no need to upstream this change. Author: Simon Ruderich <si...@ruderich.org> Bug-Debian: https://bugs.debian.org/863891 Forwarded: not-needed Last-Update: 2017-06-14 Index: xpra-2.0.2/setup.py === --- xpra-2.0.2.orig/setup.py +++ xpra-2.0.2/setup.py @@ -810,6 +810,8 @@ def detect_xorg_setup(install_dir=None): def build_xpra_conf(install_dir): #generates an actual config file from the template xvfb_command = detect_xorg_setup(install_dir) +assert xvfb_command[0] == 'Xorg' +xvfb_command[0] = '/usr/lib/xorg/Xorg' from xpra.platform.features import DEFAULT_ENV def bstr(b): if b is None: signature.asc Description: PGP signature
Bug#864765: xpra: Please package latest upstream version
Package: xpra
Version: 0.17.6+dfsg-1
Severity: important
Tags: patch
Hello,
the version in Debian is very old and according to the upstream
maintainer contains multiple security relevant bugs (therefore
the important severity; sadly there's no specific list
available). Please update the package to the latest version.
Attached are patches to package the current version 2.0.2, works
fine here but was only tested for a few days on my system. The
diff also simplifies debian/rules a little, removes some patches
which I think are no longer necessary (deviation from upstream
should be minimal, but this decision might be debatable), enables
all hardening options and enables x265 support (untested).
If you don't have the time to package xpra on your own I'd be
happy to help packaging the latest upstream versions.
Regards
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
diff -u -r xpra-0.17.6+dfsg/debian/control xpra-2.0.2/debian/control
--- xpra-0.17.6+dfsg/debian/control 2016-11-10 17:24:08.0 +0100
+++ xpra-2.0.2/debian/control 2017-06-08 23:46:30.484992778 +0200
@@ -8,10 +8,12 @@
,libavcodec-dev (>= 7:3.1.3~)
,libavutil-dev (>= 7:3.1.3~)
,libswscale-dev (>= 7:3.1.3~)
+,libavformat-dev
,libvpx-dev (>= 1.6.0~)
,libwebp-dev
,libx11-dev
,libx264-dev
+,libx265-dev
,libxcomposite-dev
,libxdamage-dev
,libxkbfile-dev
diff -u -r xpra-0.17.6+dfsg/debian/patches/buildinfo.patch xpra-2.0.2/debian/patches/buildinfo.patch
--- xpra-0.17.6+dfsg/debian/patches/buildinfo.patch 2016-07-03 13:03:21.0 +0200
+++ xpra-2.0.2/debian/patches/buildinfo.patch 2017-06-08 23:37:13.286484254 +0200
@@ -8,39 +8,37 @@
* inject package version as "changes".
* reduce determinism (reproducible build).
a/add_build_info.py
-+++ b/add_build_info.py
-@@ -202,9 +202,9 @@
- return "Microsoft Windows"
- if sys.platform.find("bsd")>=0:
- return "BSD"
- if sys.platform.find("linux")>=0 and hasattr(platform, "linux_distribution"):
--return "Linux %s" % (" ".join(platform.linux_distribution()))
-+return "%s" % (" ".join(platform.linux_distribution()))
+Index: xpra-2.0.2/add_build_info.py
+===
+--- xpra-2.0.2.orig/add_build_info.py
xpra-2.0.2/add_build_info.py
+@@ -211,7 +211,7 @@ def get_platform_name():
+ from xpra.os_util import get_linux_distribution
+ ld = get_linux_distribution()
+ if ld:
+-return "Linux %s" % (" ".join(ld))
++return "%s" % (" ".join(ld))
+ except:
+ pass
return sys.platform
-
-
- BUILD_INFO_FILE = "./xpra/build_info.py"
-@@ -216,12 +216,13 @@
- import getpass
+@@ -227,11 +227,12 @@ def record_build_info(is_build=True):
set_prop(props, "BUILT_BY", getpass.getuser())
except:
set_prop(props, "BUILT_BY", os.environ.get("USER"))
-set_prop(props, "BUILT_ON", socket.gethostname())
-set_prop(props, "BUILD_DATE", datetime.date.today().isoformat())
-set_prop(props, "BUILD_TIME", datetime.datetime.now().strftime("%H:%M"))
--set_prop(props, "BUILD_CPU", get_cpuinfo())
+set_prop(props, "BUILT_BY", "Debian")
+set_prop(props, "BUILT_ON", "Debian")
+set_prop(props, "BUILD_DATE", subprocess.Popen("date -u --date=\"$(dpkg-parsechangelog -SDate)\" +%F", stdin=None, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, shell=True).stdout.read()[:-1])
+set_prop(props, "BUILD_TIME", subprocess.Popen("date -u --date=\"$(dpkg-parsechangelog -SDate)\" +%R", stdin=None, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, shell=True).stdout.read()[:-1])
+ set_prop(props, "BUILD_MACHINE", get_machineinfo())
+-set_prop(props, "BUILD_CPU", get_cpuinfo())
+set_prop(props, "BUILD_CPU", "Generic CPU")
set_prop(props, "BUILD_BIT", platform.architecture()[0])
set_prop(props, "BUILD_OS", get_platform_name())
try:
- from Cython import __version__ as cython_version
-@@ -268,9 +269,9 @@
- "REVISION" : "unknown",
+@@ -280,7 +281,7 @@ def get_svn_props():
"LOCAL_MODIFICATIONS" : "unknown"
}
#find revision:
@@ -49,9 +47,7 @@
(out, _) = proc.communicate()
if proc.returncode!=0:
print("'svnversion -n' failed with return code %s" % proc.returncode)
- return props
-@@ -295,9 +296,9 @@
- rev = int(rev_str)
+@@ -307,7 +308,7 @@ def get_svn_props():
props["REVISION"] = rev
#find number of local files modified:
changes = 0
@@ -60,9 +56,7 @@
(out, _) = proc.communicate()
if proc.poll()!=0:
print("could not get status of local files")
- return props
-@@ -327,9 +328,10 @@
- if ignore:
+@@ -339,7 +340,8 @@ def get_svn_props():
continue
Bug#864204: runit: Removal of runit-init removes /sbin/init breaking boot for runit users
On Mon, Jun 05, 2017 at 12:38:15PM +0300, Adrian Bunk wrote: > How would that break things for *jessie* users? > > The runit-init package is not in jessie, and the runit package in jessie > does not provide /sbin/init Ah, sorry for that. I thought that runit-init was already in Jessie and didn't verify that. Please ignore that bug for the Stretch release. But it would still be nice if the Sid users didn't get a broken system if they upgrade runit and reboot. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#864204: runit: Removal of runit-init removes /sbin/init breaking boot for runit users
Package: runit Version: 2.1.2-9.2 Severity: grave Justification: renders package unusable Hello, With the recent removal of runit-init in -9.1 /sbin/init is no longer provided breaking the boot for users depending on runit as init system. So a user happily running runit in Jessie will have a system which no longer boots in Stretch. I know runit as default init system is not supported but I see no reason to break it for any current user who happily uses runit. The recent fix in #861536 is not enough as /sbin/init is still missing. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#834942: debian-installer: Can't boot via serial console in qemu
On Sat, Feb 04, 2017 at 08:46:42PM +0100, Cyril Brulebois wrote: > Hi, > > I think this is the first time I've ever toyed with the serial > console and kvm, but at least editing the 'Install' menu option and > adding “ console=ttyS0,9600,n8” at the end of the command line lets > me have serial in ctrl-alt-3. > > I'm not sure what you proposed above should work. At least it > doesn't when trying with the latest 7.11.0 image. Are you sure > you're not missing any parameters? I just retested it and you're right, I misremembered. It works when I press in the installer and then enter the correct "console" settings, but not immediately without having access to the VGA output. Then please consider this a feature request. It would be awesome if the installer could be booted over serial without needing any graphical output. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#852398: chromium: option --enable-remote-extensions does work: extensions cannot be enabled nor be installed
severity 852398 important thanks Package: chromium Version: 56.0.2924.76-3 Followup-For: Bug #852398 Hello, Setting the option in a environment variables seems to work as workaround for me: CHROMIUM_FLAGS='--enable-remote-extensions' chromium However I urge you to change the default back to allow remote-extensions by default for stretch as this will break chromium by default for _all_ users! Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#851927: chromium: Update removed all (local) installed extensions
Package: chromium Version: 55.0.2883.75-5 Severity: important Hello, After updating to 55.0.2883.75-5 all my extensions are gone! This includes custom locally installed extensions and extensions installed from the Chrome webstore. Even after reading the NEWS article, restoring my old chrome config and using --enable-remote-extensions the extensions were still gone. Even if the --enable-rmeote-extensions switch is repaired I think this behavior to _remove_ remote extensions is highly unexpected and will surprise many stretch users and should be reverted. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#849848: blhc: Architecture independent packages shouldn't log compiler commands
On Sun, Jan 01, 2017 at 12:06:39PM +0100, Ferenc Wágner wrote: > Dear Maintainer, > > https://qa.debian.org/bls/bytag/I-no-compiler-commands.html says: > > Possible issues this might hint at: > * A package being Architecture: all, though it only contains architecture > independent data. > > which I don't get. The very point of Architecture: all packages is that they > contain architecture independent data (or code) only. So why is this flagged > as a possible issue? You're right, that doesn't sound correct. Maybe it's a typo and should say "any" instead of "all". However this is not a bug in blhc itself, but in bls and the website. Please report it to the QA mailing list debian...@lists.debian.org as mentioned on the website. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#844393: blhc still uses dpkg architecture triplets
On Tue, Nov 15, 2016 at 08:47:41AM +0100, Johannes Schauer wrote: > Hi, > > recently, dpkg switched from the triplettable to architecture > quadruplets. When now trying to run blhc with the new libdpkg-perl, one > will get: > > Undefined subroutine ::Arch::debarch_to_debtriplet called at > /usr/bin/blhc line 1032. Hello, Fixed in bf41976 [1]. Jari, could you please cherry-pick this commit and apply it to the Debian package. Regards Simon [1]: https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=bf419763b81c704b86244b0b7f0e92dda492af8a -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#843589: opendnssec: Files required for update missing
Hello again, Just noticed another update issue. All the paths given in the update README are not correct on Debian. I noticed at least /var/opendnssec vs. /var/lib/opendnssec on Debian. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#843590: opendnssec: ods-migrate can't open libsqlite3.so
Package: opendnssec Version: 1:2.0.3-1 Severity: important Hello, I followed the update instructions for 2.0 and tried to run ods-migrate, however it failed with the following error: Failed to load sqlite3 library. dlerror(): libsqlite3.so: cannot open shared object file: No such file or directory A temporary fix is easy (symlink libsqlite3.so.0 to libsqlite3.so) but I think ods-migrate should be patched to link against the correct version or at least try to dlopen the versioned so-file. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#843589: opendnssec: Files required for update missing
Package: opendnssec Version: 1:2.0.3-1 Severity: important Hello, First a minor issue, the path to the README mentioned in the update notification doesn't work, the directory /usr/share/opendnssec/1.4-2.0_db_convert is empty. But the bigger problem is that convert_sqlite doesn't work because "../../src/db/schema.sqlite" is not present in the debian package. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Mon, Oct 03, 2016 at 11:07:59PM +0200, up201407...@alunos.dcc.fc.up.pt wrote: > It's an invasion of privacy, as I said, for normal users. Sure, but that's not my use case. > In your case, if you're changing to an unprivileged user without a shell nor > password, probably some sort of "locked" account, how is an attacker going > to make use of TIOCSTI to exploit your system? (Assuming you're not going to > run untrusted applications). > > Now imagine that that locked user got compromised. Changing to a compromised > user IS and will ALWAYS be bad practice. So, if you don't know if the user > is compromised or not, don't log into that account, as simple as that. All > sorts of bad things can happen. I see your point. But there's always a trade-off between security and usability. And logging in as a (possibly compromised) user makes working with user separation much easier and should still be as secure as possible (that's why I want to fix su and sudo). I know an attacker could exploit my terminal emulator when I log in, but it's better than no isolation at all IMHO. Anyway, this is off-topic, so let's take this off-list if you want to discuss it further. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Mon, Oct 03, 2016 at 09:58:23PM +0200, up201407...@alunos.dcc.fc.up.pt wrote: > Anyways, it is bad admin practice and/or an invasion of privacy to su to an > unprivileged user. Please explain to me why this is bad admin practice. Lets assume I have an unprivileged user which is used to execute a script in an isolated context. Now that script breaks and I have to debug it. The user has no shell nor password. How do I run a command as that user? What I did in the past was to run su -s /bin/sh user and then debug and fix the problem. What is wrong with that setup? > This has been talked alot in the past, in most of the times even closed as > "WONTFIX". In that case su should prevent a user from doing it, not causing a security hole and not documenting that fact. > What I'm saying is, it's OK if you can't come up with something. Better use > 'su -c' in any case. Often a terminal with a shell makes debugging much less painful. su -c doesn't help there. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Mon, Oct 03, 2016 at 09:49:08PM +0200, Karel Zak wrote: > Yes, I'm thinking about this way (as discussed on util-linux > mailing list), but it's relatively complex. I have a working solution here. It's a standalone program and not very well tested, but works fine for me. Just tell me if you want to get the source. (Disclaimer: I'm no terminal expert, so be careful with trusting it too much.) This bug also has some patches which implement exactly that and may just need a little refinement. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Mon, Oct 03, 2016 at 09:22:50PM +0200, up201407...@alunos.dcc.fc.up.pt wrote: > Loss of job control in the shell. I'm confused. I'm not talking about removing the controlling terminal, but instead spawning a new session, opening a new pts and connecting that to the program. This way the program has a tty, job control works, but the tty is different and therefore can't be controlled by the less-privileged account. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Mon, Oct 03, 2016 at 04:22:47PM +0200, Karel Zak wrote: > The problem is that we don't want to use setsid() in all situations, > because it will introduce regressions. From util-linux ReleaseNotes: Hello, Thanks for your quick reply. In which situations will this cause regressions? I tried to find cases where this will break, but I can't think of any (I guess that's because I'm just using su in a very basic way). Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Mon, Oct 03, 2016 at 04:11:41PM +0200, up201407...@alunos.dcc.fc.up.pt wrote: > Btw, at least in redhat based systems, su uses setsid() when the -c option > is given, just like use_pty in sudo. Not sure if this is true in debian. Yes, that's true in Debian as well. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#657784: CVE-2005-4890: tty hijacking possible in "sudo" via TIOCSTI ioctl
Source: sudo Followup-For: Bug #657784 Hello, Any news on this? The default still doesn't include use_pty which makes sudo vulnerable. The security-tracker lists this bug as fixed [1], however sudo in sid (and stable) is still affected. Regards Simon [1]: https://security-tracker.debian.org/tracker/CVE-2005-4890 -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Sun, Oct 02, 2016 at 10:54:06AM +0200, up201407...@alunos.dcc.fc.up.pt wrote: > Hello Simon, > > This has been recently patched by using seccomp to blacklist this ioctl. > > https://github.com/karelzak/util-linux/commit/8e4925016875c6a4f2ab4f833ba66f0fc57396a2 Hello, This is an awful hack! Blacklisting this single ioctl will fix only this specific issue, but the underlying problem, that the unprivileged user has access to the original tty, is still unfixed. The (later) patches in this bug report go in a different direction and fix the underlying problem by opening a new session with a separate tty and "proxying" the output (SSH also uses this approach - only over the network). This seems to me like a much better option than blacklisting a single ioctl. @Karel: Could you please have a look at the patches in this bug report which use setsid() to create a new session and adapt your commit with a patch based on this approach? Sudo's use_pty option does the same to fix this issue (but not enabled by default). Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
Package: login Version: 1:4.2-3+deb8u1 Followup-For: Bug #628843 Hello, Any news on this? I'm deeply worried that this security issue in su was not fixed since it was reported over 5 years ago! It still affects jessie and sid. And the possible implications are not mentioned in the man page. As this breaks the use of su to change to less-privileged users, what is the recommendation to perform this task without using su? Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x1972F726F0D556E7 signature.asc Description: Digital signature
Bug#837368: blhc does not detect hardening fail in magicrescue
On Sat, Sep 10, 2016 at 10:31:39PM -0300, Eriberto Mota wrote: > Control: reassign 837368 hardening-includes > > Hi Simon, > > Thanks a lot for your explantion below. I am forwarding this bug to > package hardening-includes, which provides hardening-check. Hello Eriberto, As I said, there's nothing to fix here. hardening-check can't know the difference. That's also the reason why lintian doesn't report this as error because it's basically just a guess. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#837368: blhc does not detect hardening fail in magicrescue
On Sat, Sep 10, 2016 at 09:15:43PM -0300, Joao Eriberto Mota Filho wrote: > Hi, > > When building my package magicrescue in Sid, lintian says: > > I: magicrescue: hardening-no-fortify-functions > usr/lib/magicrescue/tools/safecat > > Using hardening-check, I can see: > > # hardening-check > /tmp/magicrescue-1.1.9/debian/magicrescue/usr/lib/magicrescue/tools/safecat >Position Independent Executable: yes >Stack protected: yes >Fortify Source functions: no, only unprotected functions found! >Read-only relocations: yes >Immediate binding: yes > > However, blhc --all says nothing. It is a false positive from hardening check > or a blhc bug? Hello, TL;DR everything is fine. No bug in neither blhc nor hardening-check and all hardening flags are applied. After looking at the build logs this is a false positive in hardening-check (that's impossible to fix for now). -D_FORTIFY_SOURCE=2 is passed to all gcc calls in the build log therefore blhc reports no errors. However hardening-check can only look at the resulting binary. Now it looks like magicrescue doesn't use any of the protected functions generated by -D_FORTIFY_SOURCE=2 as gcc has converted all calls to the unsafe version because it can prove that the arguments can't overflow. hardening-check interprets this as possible missing hardening flags and warns. As hardening-check has no access to the build log it can't do any better. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#833939: blhc: False positives with Ada and format flags.
On Sat, Sep 10, 2016 at 09:07:13PM -0300, Eriberto wrote: > Please, release a new version and I will do a NMU quickly. I wil open > a new bug now. Please, check it before release a new version. Hi, New version 0.07 released: https://ruderich.org/simon/blhc/ Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#833939: blhc: False positives with Ada and format flags.
On Thu, Aug 25, 2016 at 11:59:05PM +0200, Nicolas Boulenguez wrote: > Here is what should be implemented: > When * the source file name matches "*.ad[abs]", > or * the command line contains " -x ada ", > we are compiling an Ada source. > Then * no CPPFLAGS should be used at all, > * all CFLAGS should be used, but "-Wformat" and "-Werror=format-security" Hi, Should be fixed in 42b57f [1]. blhc's maintainer seems to be MIA (see also #837094). If you want to see this in Debian soon please upload this change (and also #828789 if possible) via NMU. If a new blhc release would make this simpler, just tell me and I'll release one (it's only 4 commits). Regards Simon [1]: https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commit;h=42b57fd5396d424483fb2856a3f2abc6ffae2fc4 -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#836886: softhsm: Migrating to softhsm2 and purgin softhsm removes softhsm group
Package: softhsm Severity: normal Hello, After migrating from softhsm to softhsm2 I purged softhsm. However this removed the softhsm group which is still in use by softhsm2 thus breaking opendnssec which is now no longer in this group and can't access the hsm. Btw. why is a static gid (999) used instead of a dynamic system's group id? Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#828789: False-positive on samba build
On Mon, Jun 27, 2016 at 10:26:55PM +0200, Mathieu Parent wrote:
> Hello,
>
> blhc outputs:
> CPPFLAGS missing (-D_FORTIFY_SOURCE=2): 19:49:25 runner
> ../source3/script/build_env.sh /build/samba-4.4.4+dfsg/source3
> /build/samba-4.4.4+dfsg/source3 /usr/bin/gcc >
> default/source3/include/build_env.h
>
> Here, gcc is just ${CC} expanded by waf. No compilation is done.
>
> Maybe gcc followed by ">" can always be ignored?
Hello,
Should be fixed in e00e2e [1].
Regards
Simon
[1]:
https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=e00e2e347199b213d24540949b832d14cf5bd5dc
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
signature.asc
Description: PGP signature
Bug#833939: blhc: False positives with Ada and format flags.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, Aug 10, 2016 at 05:37:26PM +0200, Nicolas Boulenguez wrote: > Hello, it's me again :-) Oh no ;-) > Here is again a false positive about --format options missing during > an Ada compilation, similar to #719656 and #680117: > https://buildd.debian.org/status/fetch.php?pkg=ada-reference-manual=all=1%3a2012.2-9=1461784158 There seem to be two issues in this build log. The first occurs because .o is generated from .adb: CFLAGS missing (-Wformat -Werror=format-security): gcc-6 -c -I./ -I../progs -g -O2 -fPIE -fstack-protector-strong -gnat2005 -gnato -gnatVa -fstack-check -gnatw.I -I- -o /«PKGBUILDDIR»/build/objects/arm_frm.o /«PKGBUILDDIR»/progs/arm_frm.adb I assume it's fine to ignore -Wformat* here. Is this correct? The second appears is the following two lines: CFLAGS missing (-Wformat -Werror=format-security): gcc-6 -c -I./ -I../progs -g -O2 -fPIE -fstack-protector-strong -gnat2005 -gnato -gnatVa -fstack-check -I- -x ada -o /«PKGBUILDDIR»/build/objects/arm_form.o /«PKGBUILDDIR»/progs/arm_form.ada CPPFLAGS missing (-D_FORTIFY_SOURCE=2): gcc-6 -c -I./ -I../progs -g -O2 -fPIE -fstack-protector-strong -gnat2005 -gnato -gnatVa -fstack-check -I- -x ada -o /«PKGBUILDDIR»/build/objects/arm_form.o /«PKGBUILDDIR»/progs/arm_form.ada I don't know what .ada is used for. Can I treat it like .adb with the same flag restrictions? How should CPPFLAGS be treated? Regards Simon - -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 -BEGIN PGP SIGNATURE- iQIbBAEBCgAGBQJXvxqxAAoJEJL+/bfkTDL5eowP+IPjOzcQASXKikCw5tVJrZKh 2wQn8OLt52Ri7cs/BajM2krA9MCTUccroXwJbaahDJ/kUG0dYJRfbaifCMl1WkZ3 /Pi0Zu1oQonZsENBmWmZc15fdjdWO10dF7Ph2GTu4WmMyVF8QBAD6g3cfHq/4ZMv ZgzfzrdcUVGOFWu0VcJs06xGANymkDsVZwRERr8sZrZDVOlCspc9p568sfClSrmJ hMLf2Dw0cLOcJbk8pKndLf3WFoqjT4ymJjn0V4eyLt1N14jKgwSgNjYdThV/Rrs3 FpN3mf239A/71HKfbEclOMv/rWNjn93rILrTXYfJPO5hRF0q+57dVkXTcGO8zE6x RtpvYNWwJxmZvFYOWXnkc5zW4JtJ4zYAptDC4242GIsu7FKVmkBD6bFJSjsWiSQr jzzpGMnauQ/WmGPWEAkhfVNr+bFjZuA5fr88tzxIh3FIL6d+idgZESxZ4mZQgT8V GR5ws6MS4Gpus28giQuNK4rPtF1HQ8pC68S76nak/G1/om8D/dXug25/l1g1vM96 t5OAaVDcvGn2ig0CXA57/aRNJ2+gwfDpkkTbFbuUQRnJyDVUleyYB3+HOKIYtA2F CBBLmdTnA0bwYDpQVmRazkevkKaZGeTcqASgknnRxZYfN1wa5//ivIr9WO+jRI3C Q9OnLfBO8Hd8br0tJIE= =nMv5 -END PGP SIGNATURE-
Bug#834942: debian-installer: Can't boot via serial console in qemu
Package: debian-installer Version: 8.5.0 Severity: normal Hello, I can't boot the debian installer via serial console in qemu: qemu-system-x86_64 -boot d -cdrom debian-8.5.0-amd64-netinst.iso -nographic I'd expect a prompt from isolinux on the serial console which lets me change the boot parameters. I have no real system to verify this, but IIRC then it worked in the past. Am I using qemu or the installer incorrectly or did this behavior change? Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#833275: python3-django: django-admin startproject creates incorrect shebang
Package: python3-django Version: 1:1.10-2 Severity: normal Hello, django-admin startproject foo creates manage.py with the following shebang: #!/usr/bin/env python However on Debian python is python2 and not python3, therefore running manage.py fails because it can't find the django module (I only installed python3-django). It should use instead python3 in the shebang. I'm not sure if there's an easy fix, as manage.py-tpl is provided by python-django-common. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#807369: apparmor: Apparmor "deny network" not working in Jessie
On Mon, Jun 27, 2016 at 11:15:26PM +0100, Simon McVittie wrote: > On Thu, 11 Feb 2016 at 17:03:22 +0100, Simon Ruderich wrote: >> Without network mediation local UNIX access is a big >> problem (DBUS). > > [snip] > > Normal filesystem-backed Unix sockets are mediated by ordinary file-based > AppArmor rules, so they are much easier to sandbox. > > [snip] Sadly that's not correct in Debian at the moment. That part of the AppArmor code is still missing in the Debian kernel. To restrict access for UNIX-Sockets the normal file hooks are not sufficient and the unix_stream_connect and unix_may_send hooks must be used. This part is still missing in Debian making any restrictions to for example DBUS or all other Unix-Sockets impossible! (And in contrast with IP sockets, UNIX sockets they can't be constrained with iptables.) Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#399002: libpam-krb5: allow TGT verification by non-root processes
>On Fri, Jun 10, 2016 at 09:31:47PM +0200, Simon Ruderich wrote: >> Instead of installing the helper as setuid one could also install >> it as setgid with a specific kerberos group which can read the >> keytab. Then in the worst case the keytab is compromised. The >> existing patch supports this approach. Any objections against using it as setgid instead of setuid? This would work fine as well and prevent serious privilege escalation. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x1972F726F0D556E7 signature.asc Description: Digital signature
Bug#399002: libpam-krb5: allow TGT verification by non-root processes
On Fri, Jun 10, 2016 at 10:47:16AM -0700, Russ Allbery wrote: > I'm too nervous about the many possible attack approaches to setuid > binaries to be entirely comfortable with this approach. My tentative > thought about the right way to approach this was to instead add a daemon > that listens on a UNIX domain socket for validation requests and replies > with simple success or failure. That sort of oracle should be okay to > expose to the rest of the system, and running it as a separate daemon will > remove the security concerns about setuid. What possible attack approaches are you thinking of? If you're worrying about the environment, there is a simple solution: >> In case you think this is problematic we could easily split the >> wrapper into two binaries, where the first (setuid) is not linked >> to Kerberos and the second (not-setuid) performs the validation. There is no real difference between this approach and running a daemon as root, as the environment is cleared before calling the program which reads the keytab. Instead of installing the helper as setuid one could also install it as setgid with a specific kerberos group which can read the keytab. Then in the worst case the keytab is compromised. The existing patch supports this approach. > (It does mean some additional operational complexity to start and manage > the daemon, but the Debian package, at least, can easily take care of > that.) Having another critical component in the authentication process which can break seems overly complex to me. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x1972F726F0D556E7 signature.asc Description: Digital signature
Bug#399002: libpam-krb5: allow TGT verification by non-root processes
Package: src:libpam-krb5
Followup-For: Bug #399002
Hello,
Revised patch attached which adds support for Heimdal (the Debian
package with our patch builds fine now) and fixes backwards
compatibility with verify_ap_req_nofail = false (the old patch
always rejected missing KDC validation even if
verify_ap_req_nofail was set to false).
Regards
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x1972F726F0D556E7
From 38dc32de02d7f5e09af4679d437e459eec441a82 Mon Sep 17 00:00:00 2001
Message-Id: <38dc32de02d7f5e09af4679d437e459eec441a82.1465574311.git.si...@ruderich.org>
From: Simon Ruderich <si...@ruderich.org>
Date: Fri, 10 Jun 2016 17:16:43 +0200
Subject: [PATCH] Add setuid helper to allow TGT verification by non-root
processes
To prevent KDB spoofing the Kerberos option verify_ap_req_nofail = true
can be used to verify that the ticket originates from the same KDC which
provided the host keytab. However if a PAM program is not running as
root, it can't read the keytab and thus can't perform this validation.
Add a setuid helper which performs the authentication when running not
as root.
The helper performs a manual AP_REQ/AP_REP exchange to authenticate the
KDC against the host keytab.
verify_ap_req_nofail is respected and behaves as before.
The helper supports both setuid root and setgid to a separate group
(with access to /etc/krb5.keytab). Per default setuid is used which
should require no changes on most systems.
---
.gitignore| 1 +
Makefile.am | 8 ++-
auth.c| 214 +-
krb5_vfycrd.c | 150
4 files changed, 371 insertions(+), 2 deletions(-)
create mode 100644 krb5_vfycrd.c
diff --git a/.gitignore b/.gitignore
index c282488..5aea49f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,6 +9,7 @@
/config.log
/config.status
/configure
+/krb5_vfycrd
/libtool
/m4/libtool.m4
/m4/ltoptions.m4
diff --git a/Makefile.am b/Makefile.am
index 0cdf2ff..a6f02de 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -18,7 +18,7 @@ EXTRA_DIST = .gitignore LICENSE autogen pam_krb5.map pam_krb5.pod \
tests/tap/libtap.sh
# Everything we build needs the Kerbeors headers and library flags.
-AM_CPPFLAGS = $(KRB5_CPPFLAGS)
+AM_CPPFLAGS = $(KRB5_CPPFLAGS) -DKRB5_VFYCRD_PATH=\"$(sbindir)/krb5_vfycrd\"
AM_LDFLAGS = $(KRB5_LDFLAGS)
noinst_LTLIBRARIES = pam-util/libpamutil.la portable/libportable.la
@@ -30,6 +30,12 @@ pam_util_libpamutil_la_SOURCES = pam-util/args.c pam-util/args.h \
pam-util/logging.c pam-util/logging.h pam-util/options.c \
pam-util/options.h pam-util/vector.c pam-util/vector.h
+sbin_PROGRAMS = krb5_vfycrd
+krb5_vfycrd_LDADD = $(KRB5_LIBS)
+
+install-exec-hook:
+ chmod 4755 $(DESTDIR)$(sbindir)/krb5_vfycrd
+
if HAVE_LD_VERSION_SCRIPT
VERSION_LDFLAGS = -Wl,--version-script=${srcdir}/pam_krb5.map
else
diff --git a/auth.c b/auth.c
index 6d35bd0..ed8c68c 100644
--- a/auth.c
+++ b/auth.c
@@ -27,6 +27,10 @@
#endif
#include
#include
+#include
+#include
+#include
+#include
#include
#include
@@ -632,7 +636,7 @@ password_auth_attempt(struct pam_args *args, const char *service,
* Returns a Kerberos status code (0 for success).
*/
static krb5_error_code
-verify_creds(struct pam_args *args, krb5_creds *creds)
+verify_creds_normal(struct pam_args *args, krb5_creds *creds)
{
krb5_verify_init_creds_opt opts;
krb5_keytab keytab = NULL;
@@ -678,6 +682,214 @@ verify_creds(struct pam_args *args, krb5_creds *creds)
return retval;
}
+static krb5_error_code
+verify_creds_setuid_helper(struct pam_args *args, krb5_creds *creds)
+{
+pid_t pid;
+int fd_stdin[2];
+int fd_stdout[2];
+struct sigaction temp_sa, saved_sa;
+int retval = KRB5KRB_ERR_GENERIC; /* need to return KRB5 error codes */
+
+if (pipe(fd_stdin)) {
+return retval;
+}
+if (pipe(fd_stdout)) {
+close(fd_stdin[0]);
+close(fd_stdin[1]);
+return retval;
+}
+
+/* Install a temporary signal handler for SIGCHLD to prevent the
+ * application from receiving unexpected signals.
+ *
+ * TODO: noreap pam module option like pam_unix.so? */
+memset(_sa, 0, sizeof(temp_sa));
+temp_sa.sa_handler = SIG_DFL;
+sigemptyset(_sa.sa_mask);
+sigaction(SIGCHLD, _sa, _sa);
+
+pid = fork();
+if (pid > 0) {
+/* parent */
+uint32_t length_princ, length_req, length_rep; /* see krb5_vfycrd.c */
+
+FILE *chld_stdin, *chld_stdout;
+char buf[4096];
+krb5_data packet_req, packet_rep;
+krb5_context ctx = args->config->ctx->context;
+krb5_principal server_princ = NULL;
+krb5_auth_context auth_ctx = NULL;
+krb5_ccache ccache = NULL;
+krb5_creds creds_server_in, *creds_server = NULL;
+krb5_ap_rep_enc_part *reply;
+
+packet_req.data = NULL;
+packet_rep.data =
Bug#399002: libpam-krb5: allow TGT verification by non-root processes
Package: src:libpam-krb5
Followup-For: Bug #399002
Hello,
The attacked patch adds a setuid-wrapper to allow verification of
the keytab for non-root PAM programs.
The new verify_creds_setuid_helper function forks our new suid
helper binary against which it does a standard kerberos service
authentication by getting a service ticket from the KDC and
sending a AP_REQ and verifying the resulting AP_REP it receives.
In case the PAM process is called as root or a custom keytab was
provided as PAM module option the old code is used.
The helper doesn't drop privileges at the moment because it
complicates the code and we're not sure how non-Linux systems
behave regarding dropped privileges and ptrace/core dumps.
To prevent possible attacks we've chosen to keep the setuid
privileges during the run of the helper. As the Kerberos library
must support untrusted input anyway, this should cause no issues.
However there's one potential problem with the setuid helper. The
Kerberos library uses init-functions which initialize for example
gettext on load. The setuid helper can only clean the environment
after these init-functions are run so an attacker could inject
environment variables. We don't know if this could be an issue.
In case you think this is problematic we could easily split the
wrapper into two binaries, where the first (setuid) is not linked
to Kerberos and the second (not-setuid) performs the validation.
Regards
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x1972F726F0D556E7
From 01139eb31b3f3f6c41b425e492d5146499b4e0e2 Mon Sep 17 00:00:00 2001
Message-Id: <01139eb31b3f3f6c41b425e492d5146499b4e0e2.1465566262.git.si...@ruderich.org>
From: Simon Ruderich <si...@ruderich.org>
Date: Fri, 10 Jun 2016 14:48:02 +0200
Subject: [PATCH] Add setuid helper to allow TGT verification by non-root
processes
To prevent KDB spoofing the Kerberos option verify_ap_req_nofail = true
can be used to verify that the ticket originates from the same KDC which
provided the host keytab. However if a PAM program is not running as
root, it can't read the keytab and thus can't perform this validation.
Add a setuid helper which performs the authentication when running not
as root.
The helper performs a manual AP_REQ/AP_REP exchange to authenticate the
KDC against the host keytab.
verify_ap_req_nofail is respected and behaves as before.
The helper supports both setuid root and setgid to a separate group
(with access to /etc/krb5.keytab). Per default setuid is used which
should require no changes on most systems.
---
.gitignore| 1 +
Makefile.am | 8 ++-
auth.c| 207 +-
krb5_vfycrd.c | 126 +++
4 files changed, 340 insertions(+), 2 deletions(-)
create mode 100644 krb5_vfycrd.c
diff --git a/.gitignore b/.gitignore
index c282488..5aea49f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,6 +9,7 @@
/config.log
/config.status
/configure
+/krb5_vfycrd
/libtool
/m4/libtool.m4
/m4/ltoptions.m4
diff --git a/Makefile.am b/Makefile.am
index 0cdf2ff..a6f02de 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -18,7 +18,7 @@ EXTRA_DIST = .gitignore LICENSE autogen pam_krb5.map pam_krb5.pod \
tests/tap/libtap.sh
# Everything we build needs the Kerbeors headers and library flags.
-AM_CPPFLAGS = $(KRB5_CPPFLAGS)
+AM_CPPFLAGS = $(KRB5_CPPFLAGS) -DKRB5_VFYCRD_PATH=\"$(sbindir)/krb5_vfycrd\"
AM_LDFLAGS = $(KRB5_LDFLAGS)
noinst_LTLIBRARIES = pam-util/libpamutil.la portable/libportable.la
@@ -30,6 +30,12 @@ pam_util_libpamutil_la_SOURCES = pam-util/args.c pam-util/args.h \
pam-util/logging.c pam-util/logging.h pam-util/options.c \
pam-util/options.h pam-util/vector.c pam-util/vector.h
+sbin_PROGRAMS = krb5_vfycrd
+krb5_vfycrd_LDADD = $(KRB5_LIBS)
+
+install-exec-hook:
+ chmod 4755 $(DESTDIR)$(sbindir)/krb5_vfycrd
+
if HAVE_LD_VERSION_SCRIPT
VERSION_LDFLAGS = -Wl,--version-script=${srcdir}/pam_krb5.map
else
diff --git a/auth.c b/auth.c
index 6d35bd0..b60e63c 100644
--- a/auth.c
+++ b/auth.c
@@ -27,6 +27,10 @@
#endif
#include
#include
+#include
+#include
+#include
+#include
#include
#include
@@ -632,7 +636,7 @@ password_auth_attempt(struct pam_args *args, const char *service,
* Returns a Kerberos status code (0 for success).
*/
static krb5_error_code
-verify_creds(struct pam_args *args, krb5_creds *creds)
+verify_creds_normal(struct pam_args *args, krb5_creds *creds)
{
krb5_verify_init_creds_opt opts;
krb5_keytab keytab = NULL;
@@ -678,6 +682,207 @@ verify_creds(struct pam_args *args, krb5_creds *creds)
return retval;
}
+static krb5_error_code
+verify_creds_setuid_helper(struct pam_args *args, krb5_creds *creds)
+{
+pid_t pid;
+int fd_stdin[2];
+int fd_stdout[2];
+struct sigaction temp_sa, saved_sa;
+int retval = KRB5KRB_ERR_GENERIC; /* need to return KRB5 error codes */
+
+if (pipe(fd_stdin)) {
Bug#825428: blhc: FTBFS with Perl 5.24: Pod::Usage formatting changed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, Jun 05, 2016 at 12:36:30AM +0200, gregor herrmann wrote: > Yup, Pod::Usage changed its output in 1.65: > > https://metacpan.org/diff/file?target=MAREKR%2FPod-Usage-1.65%2F=MAREKR%2FPod-Usage-1.64%2F#lib/Pod/Usage.pm > > Attached is a (rather ugly) patch that works with (Pod::Usage in) > perl 5.22 and 5.24. On Sun, Jun 05, 2016 at 01:23:53AM +0200, gregor herrmann wrote: > On Sat, 04 Jun 2016 20:20:26 -0300, Eriberto Mota wrote: > > > Gregor, please, do a delayed NMU. > > The current maintainer is a bit MIA... > > Thanks for the heads-up. > > Will NMU when perl 5.24 is getting closer to unstable; I wanted to > give people a chance to come up with a better patch than mine until > then :) Hello Gregor, Thanks for your patch. I've applied it to blhc [1] and released 0.06 [2] which contains this fix and fixes for multiple open bugs. When you perform the NMU, could you please upload the latest version of blhc? It fixes the following open bugs: #825428 (this bug) #765756 blhc: gets confused by output from gcc -v, g++ -v and reports false positives #784959 blhc: possible false positive about missing CPPFLAGS in a linker call #801492 blhc: false positive for non verbose build #825671 blhc: false positives for comment lines #772853 blhc: false positive: LDFLAGS missing (-Wl, -z, relro): rm -f afl-gcc ... Regards Simon [1]: https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=4c5b4aedc1dcf125701393371013c47c35c7772b [2]: https://ruderich.org/simon/blhc/ - -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJXVDKWAAoJEJL+/bfkTDL5llMP/13WYuSMAnWM1e5yREOLAacp jHL130OVYaub/Wl9OuQYWM+O6cuX9KhHCSPBsyJKeSXRSIZR+WyIoFlzRhPTCaER HDVA0myOoXWHxhYRi3649Hu52jE50ysua5Y4/B6LzclwdBXXTKH33gXa4sOzXdYJ IryVKNkqIdYAnS5T4cNvQC5GGWDsQbbBhvYBayQLfNfUu/ZctO7H3uoXdH36ZscF DJCwp3Otl8/kLdNR7RRfb+MzkFsXuDREN0AV9g0dJ5UV7uxYmiMuVTGwJWTnUuQw hbgNw8zNQd9KBw2GI54ao1PcY8TXHLtWXB9a4FTQOS9hw6j4wJ/GvCZpumaeIGyB gcXPxBK6DaPqPUoN7aj1v3eACVenRV9d923T5JblnMTMZ8b4YA/89NmT+sxpUUop ez6XAFwK/VoCzqOwxCeTJiLIn0KVyoAxg++uIgoj82e/ygAofYUKt9AkcSUdb2ZG OQH84GCttCRul3aAFKiXyyPxu4RMc2gUDLQInOjK0aX+x+f/QVknvmRPxW8U+zIu ylJwIyc3bHVoLnqqJFHi+Z3XdFzGYGMcT/b/ekVlTC7Y/awxLpuha6B1Pe9NL6Db QKSruqe+jBg8CX6wKvB1sQZAVQIeu3LTTuV/b67+kL8ZEUvSXm4s9dOVifw0IeBW HlpsjYZ83ZvFJbW+iZ9b =LVUE -END PGP SIGNATURE-
