Bug#981545: ITS: openscap
On Mon, Feb 01, 2021 at 09:43:19AM +0100, Håvard Flaget Aasen wrote: > Package: openscap > Severity: important > Version: 1.2.17-0.1 > > Dear openscap maintainer, > [...] > > Please let me know if you are still willing to maintain this package. > According to the criteria listed at [3], I will upload a Non-maintainer > Upload (NMU) of openscap onto DELAYED/7 after 21 days (2021-02-23) to > continue with the package salvaging If it's necessary to pause the ITS > process, please let me know immediately by replying this bug report. > > Thank you for your previous work in Debian and looking forward to your > reply. I know I waited for too long, but there are already some actions in progress. Please do not upload the NMU yet, I am currently already in the process of transferring the packaging data to Philippe Thierry, which maintains openscap-daemon (added to CC). The result would be maintained collaboratively, so please coordinate with Philippe for next uploads. Thanks, Pierre
Bug#928294: unblock: suricata/4.1.4-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Although it is an upstream release, please unblock suricata 4.1.4-1 for buster. Suricata is an Intrusion Detection System (IDS), which makes it exposed to malicious traffic by design. The upstream release 4.1.4 fixes several bugs and security issues (no CVE numbers). The debdiff since 4.1.3 is too big to be included here (it contains updates to many auto-generated files like configure), so I'm adding the upstream changelog here: Changes Bug #2870: pcap logging with lz4 coverity warning Bug #2883: ssh: heap buffer overflow Bug #2884: mpls: heapbuffer overflow in file decode-mpls.c Bug #2887: decode-ethernet: heapbuffer overflow in file decode-ethernet.c Bug #2888: 4.1.3 core in HCBDCreateSpace Bug #2894: smb 1 create andx request does not parse the filename correctly Bug #2902: rust/dhcp: panic in dhcp parser Bug #2903: mpls: cast of misaligned data leads to undefined behavior Bug #2904: rust/ftp: panic in ftp parser Bug #2943: rust/nfs: integer underflow This release includes Suricata-Update 1.0.5 I hope the new version can be included. Best regards, Pierre
Bug#912977: iptables: nftables layer breaks ipsec/policy keyword
On Tue, Nov 06, 2018 at 02:02:06PM +0100, Arturo Borrero Gonzalez wrote: > Control: forwarded -1 https://bugzilla.netfilter.org/show_bug.cgi?id=1290 > > Hopefully next upstream release will contain a fix. Hi, Thanks Arturo. After some more testing, it seems the bug would be less severe than it looks: - the (iptables) rules seems to work, the nft dump can just not show them (which is a bug, but less important) This was tested for the policy module, for OUTPUT. - the iptables rules can be saved and reloaded as usual - the produced nft ruleset should not be used (for ex to switch to nftables), as it will load without error but without the nft_compat keywords. This would also be a different bug. I'm still running some more tests, but I think the severity can be lowered. Regards, Pierre
Bug#912977: iptables: nftables layer breaks ipsec/policy keyword
Package: iptables
Version: 1.8.1-2
Severity: grave
Tags: security
Justification: breaks rules, inserts pass-all rules
X-Debbugs-Cc: t...@security.debian.org,
secure-testing-t...@lists.alioth.debian.org
Hi,
The debian package for iptables now transparently converts inserted
rules to nftables, which is great.
However, some keywords are not supported (like the 'policy' keyword for
IPsec transforms). The bad part is, these rules are inserted
*without* the matches, which makes in some cases your firewall useless.
For ex:
# iptables -F
# iptables -A OUTPUT -m policy --dir out --pol ipsec --strict --mode tunnel -o
eth0 -j ACCEPT
# echo $?
0
# nft list ruleset
chain OUTPUT {
type filter hook output priority 0; policy accept;
oifname "eth0" counter packets 90 bytes 26085 accept
}
}
As you can see, the inserted rule allows everything, while the expected
behavior would be 'only if going through an IPsec tunnel'.
Even worse: inserting the rule did not fail.
Until the 'ipsec' (or 'secpath') keyword works properly (and supports
all options), an acceptable behavior would be to reject the rule if one
or more keywords are not supported by nftables.
Regards,
Pierre
Bug#897465: sagan: FTBFS: ./conftest.c:120: undefined reference to `strlcat'
close 897465 1.1.8-2 done On Thu, May 03, 2018 at 11:55:18AM +0200, Lucas Nussbaum wrote: > On 03/05/18 at 11:22 +0200, Pierre Chifflier wrote: > > tags 897465 - moreinfo unreproducible > > severity 897465 normal > > thanks > > > > Hi Lucas, > > > > I cannot reproduce this FTBFS here (in pbuilder), nor in a porter box. > > However, I just uploaded sagan-1.1.8-2, where a build-dep was missing. > > > > These issues may be related (though I don't see how). Can you test again > > and confirm if it is fixed ? > > Not easily. > > Could you post a build-log (and a diff with mine) to see if something > obvious comes up? > Hi, In fact, the error was not strlcat (this error is not fatal) but the missing libyaml-dev build-dep: even in your log, the error appears at line 955. I was confused because this is not the last error in the log file. So, this bug is indeed fixed by 1.1.8-2, I'm closing it. That said, i386 is still failing because of some inline assembly (reported upstream). Thanks, Pierre
Bug#897465: sagan: FTBFS: ./conftest.c:120: undefined reference to `strlcat'
tags 897465 - moreinfo unreproducible severity 897465 normal thanks Hi Lucas, I cannot reproduce this FTBFS here (in pbuilder), nor in a porter box. However, I just uploaded sagan-1.1.8-2, where a build-dep was missing. These issues may be related (though I don't see how). Can you test again and confirm if it is fixed ? Thanks, Pierre On Wed, May 02, 2018 at 10:05:20PM +0200, Lucas Nussbaum wrote: > Source: sagan > Version: 1.1.8-1 > Severity: serious > Tags: buster sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20180502 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part (hopefully): > > gcc: fatal error: no input files > > compilation terminated. > > configure:5639: $? = 1 > > configure:5643: checking whether we are using the GNU C compiler > > configure:5671: result: yes > > configure:5680: checking whether gcc accepts -g > > configure:5741: result: yes > > configure:5758: checking for gcc option to accept ISO C89 > > configure:5834: result: none needed > > configure:5859: checking whether gcc understands -c and -o together > > configure:5896: result: yes > > configure:5920: checking whether make sets $(MAKE) > > configure:5942: result: yes > > configure:6008: checking for pkg-config > > configure:6026: found /usr/bin/pkg-config > > configure:6038: result: /usr/bin/pkg-config > > configure:6063: checking pkg-config is at least version 0.9.0 > > configure:6066: result: yes > > configure:6076: checking for ANSI C header files > > configure:6180: result: yes > > configure:6188: checking for sys/wait.h that is POSIX.1 compatible > > configure:6214: gcc -c -g -O2 -fdebug-prefix-map=/<>=. > > -fstack-protector-strong -Wformat -Werror=format-security -D__Linux__ > > -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c >&5 > > configure:6214: $? = 0 > > configure:6221: result: yes > > configure:6233: checking stdio.h usability > > configure:6233: gcc -c -g -O2 -fdebug-prefix-map=/<>=. > > -fstack-protector-strong -Wformat -Werror=format-security -D__Linux__ > > -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c >&5 > > configure:6233: $? = 0 > > configure:6233: result: yes > > configure:6233: checking stdio.h presence > > configure:6233: gcc -E -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c > > configure:6233: $? = 0 > > configure:6233: result: yes > > configure:6233: checking for stdio.h > > configure:6233: result: yes > > configure:6233: checking for stdlib.h > > configure:6233: result: yes > > configure:6233: checking for sys/types.h > > configure:6233: result: yes > > configure:6233: checking for unistd.h > > configure:6233: result: yes > > configure:6233: checking for stdint.h > > configure:6233: result: yes > > configure:6233: checking for inttypes.h > > configure:6233: result: yes > > configure:6233: checking ctype.h usability > > configure:6233: gcc -c -g -O2 -fdebug-prefix-map=/<>=. > > -fstack-protector-strong -Wformat -Werror=format-security -D__Linux__ > > -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c >&5 > > configure:6233: $? = 0 > > configure:6233: result: yes > > configure:6233: checking ctype.h presence > > configure:6233: gcc -E -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c > > configure:6233: $? = 0 > > configure:6233: result: yes > > configure:6233: checking for ctype.h > > configure:6233: result: yes > > configure:6233: checking errno.h usability > > configure:6233: gcc -c -g -O2 -fdebug-prefix-map=/<>=. > > -fstack-protector-strong -Wformat -Werror=format-security -D__Linux__ > > -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c >&5 > > configure:6233: $? = 0 > > configure:6233: result: yes > > configure:6233: checking errno.h presence > > configure:6233: gcc -E -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c > > configure:6233: $? = 0 > > configure:6233: result: yes > > configure:6233: checking for errno.h > > configure:6233: result: yes > > configure:6233: checking fcntl.h usability > > configure:6233: gcc -c -g -O2 -fdebug-prefix-map=/<>=. > > -fstack-protector-strong -Wformat -Werror=format-security -D__Linux__ > > -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c >&5 > > configure:6233: $? = 0 > > configure:6233: result: yes > > configure:6233: checking fcntl.h presence > > configure:6233: gcc -E -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c > > configure:6233: $? = 0 > > configure:6233: result: yes > > configure:6233: checking for fcntl.h > > configure:6233: result: yes > > configure:6233: checking for sys/stat.h > > configure:6233: result: yes > > configure:6233: checking for string.h > > configure:6233: result: yes > > configure:6233: checking getopt.h usability > > configure:6233: gcc -c -g -O2 -fdebug-prefix-map=/<>=. > > -fstack-protector-strong -Wformat -Werror=format-security -D__Linux__ > > -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c >&5 > > configure:6233: $? = 0 > > configure:6233: result: yes > > configure:6233: checking getopt.h presence > > configure:6233: gcc -E -Wdate-time -D_FORTIFY_SO
Bug#895426: RFA: ocsinventory-agent -- Hardware and software inventory tool (client)
Package: wnpp Severity: normal Hi, I have no more time to maintain ocsinventory, so I'm RFA-ing this package. Adoption is planned by the Debian-Perl group. Pierre
Bug#895424: RFA: ocsinventory-server -- Hardware and software inventory tool (Communication Server)
Package: wnpp Severity: normal Hi, I have no more time to maintain ocsinventory, so I'm RFA-ing this package. Adoption is planned by the Debian-Perl group. Pierre
Bug#892363: missing cmx file
Package: libgetopt-ocaml-dev Version: 0.0.20040811-10+b6 Hi, When compiling a program using getopt, ocaml complains the cmx file is missing: File "_none_", line 1: Warning 58: no cmx file was found in path for module Getopt, and its interface was not compiled with -opaque File "src/main.ml", line 1: Error: Some fatal warnings were triggered (1 occurrences) Command exited with code 2. Hint: Recursive traversal of subdirectories was not enabled for this build, as the working directory does not look like an ocamlbuild project (no '_tags' or 'myocamlbuild.ml' file). If you have modules in subdirectories, you should add the option "-r" or create an empty '_tags' file. Environment: Debian sid, ocaml 4.05.0 Thanks, Pierre
Bug#831362: Bug#840848: libcap-ng FTCBFS: wrong python dependencies
On 09/25/2017 01:00 AM, Manuel A. Fernandez Montecelo wrote: > > I am submitting an NMU to delayed/15, debdiff attached, with the > combined patches (please Helmut double-check if this is the final form > that it was intended). > > If you want me to cancel the NMU just ask. > > (BTW, I checked that there are no related lintian warnings that were > mentioned in #831362). > Hi Manuel, Thanks for the patch. I'm fine with the NMU, just tell me if you prefer me to upload it directly (so we do not wait the 15 days). Regards, Pierre
Bug#875437: RM: nuapplet -- ROM; Dead upstream, needs Qt4, low popcon
Package: ftp.debian.org Severity: normal Hi, Please remove nuapplet from the archive. There is no upstream since a long time, Qt4 is going to be removed and it's popcon is low. This package depends on src:nufw, also to be removed (See #875420) Thanks!
Bug#875420: RM: nufw -- ROM; Dead upstream, needs Qt4, low popcon
Package: ftp.debian.org Severity: normal Hi, Please remove nufw from the archive. There is no upstream since a long time, Qt4 is going to be removed and it's popcon is low. Thanks!
Bug#828577: The patch is upstream
On Thu, Nov 17, 2016 at 07:47:56PM -0500, Hon Ching(Vicky) Lo wrote:
> On Thu, 2016-11-17 at 16:29 -0500, Hon Ching(Vicky) Lo wrote:
> > Hi
> >
> > The patch is upstream:
> > https://sourceforge.net/p/trousers/tpm-tools/ci/6fb8a3c5ad3bc6e62f6895a4fcf3540faa29b4f2/
> >
> >
> > Thanks,
> > Vicky
>
> The patch above is based off the latest code in tpm-tools 1.3.9. Please
> rebase to tpm-tools 1.3.9 to pick up the patch instead. Thanks!
>
Hi,
Version 1.3.9 does not fix the build with OpenSSL 1.1. It still fails
with the following error:
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -D_LINUX -Wdate-time
-D_FORTIFY_SOURCE=2 -g -O2
-fdebug-prefix-map=/home/pollux/DEBIAN/TPM-TOOLS/tpm-tools=.
-fstack-protector-strong -Wformat -Werror=format-security -m64 -Wall
-Wno-unused -Wno-implicit-function-declaration -Wreturn-type -Wsign-compare -c
-o data_import.o data_import.c
data_import.c: In function ‘readX509Cert’:
data_import.c:375:26: error: dereferencing pointer to incomplete type ‘EVP_PKEY
{aka struct evp_pkey_st}’
if ( EVP_PKEY_type( pKey->type ) != EVP_PKEY_RSA ) {
^~
In file included from /usr/include/openssl/asn1.h:24:0,
from /usr/include/openssl/rsa.h:16,
from data_import.c:34:
data_import.c: In function ‘createRsaPubKeyObject’:
data_import.c:694:34: error: dereferencing pointer to incomplete type ‘RSA {aka
struct rsa_st}’
int nLen = BN_num_bytes( a_pRsa->n );
^
Makefile:524: recipe for target 'data_import.o' failed
OpenSSL decided not to allow access to these fields anymore. At this
point, I have no idea on how to fix this.
Best regards,
Pierre
Bug#828579: The patch is upstream
On 11/18/2016 01:46 AM, Hon Ching(Vicky) Lo wrote: > On Thu, 2016-11-17 at 14:18 -0500, Hon Ching(Vicky) Lo wrote: >> The patch that supports OpenSSL 1.1 (backward-compatible) is upstream: >> https://sourceforge.net/p/trousers/trousers/ci/05411ea68746acbaf4e69295be50b9a47cddb2fd/ >> >> >> Vicky > > The patch above is based off the latest code in Trousers-0.3.14. Please > rebase to Trousers-0.3.14 to pick up the patch instead. Thanks! > Hi, I am currently trying to rebase on 0.3.14, however the upstream tarball is completely broken: - does not include the package name + version - contains .o files - has /home/lo1 hardcoded everywhere in makefiles - has wrong version in files (0.3.13 in headers) The only good news is that it seems to build with openssl 1.1.0. I'm doing my best to fix all of this, but I can't say when the upload will be done. Best regards, Pierre
Bug#836929: suricata should drop root privileges when running
On 09/07/2016 12:15 PM, Robert Haist wrote: > Package: suricata > Version: 3.1.1-4 > > It might be a security improvement to let suricata run with non-root > privileges and a special permission for the provided capture modes. > Running as root might be a problem if a protocol parser or some other > input-dependant code is exploitable. > Hi, Do you mean the following part of the config file: # Run suricata as user and group. #run-as: # user: suri # group: suri This already reduces the risk in case a parser is compromised, but using such user is not the default configuration (you have to create one and uncomment these lines). That could be added to the Debian package. Or, do you mean an additional mechanism to start as user (like file capabilities) ? Technically, file capabilities already work, however the required capability will depend on the capture method. Regards, Pierre
Bug#833628: Please package latest upstream version based on liblognorm
On Mon, Aug 08, 2016 at 11:13:51PM +0200, Michael Biebl wrote: > > You've enabled Werror. Probably because you've built directly inside the > git directory. In this case, --enable-compile-warnings= defaults to > error. I use git buildpackage, which uses a git export in a separate > build directory, so I don't run into this problem. I also use gbp, but not with export until all patches are committed. I can confirm that Werror is enabled by default here. > > You can explicitly set --enable-compile-warnings=yes in debian/rules to > avoid that. (Or disable compiler warnings completely via > --enable-compile-warnings=no, but I wouldn't recommend that) I added --enable-compile-warnings=yes > > > I also had to drop 01-fix-pkgconfig.patch, conflicting, and I think not > > necessary now. > > Yeah, this was fixed upstream > https://github.com/rsyslog/liblognorm/pull/215 > I've seen it after my email. Packages should be ready today. Regards, Pierre
Bug#833628: Please package latest upstream version based on libfastjson
On 08/07/2016 11:07 AM, Michael Biebl wrote: > Source: liblognorm > Version: 1.1.2-1.1 > Severity: important > Tags: patch > > Hi Pierre! > > The latest rsyslog version in Debian is quite outdated. The reason is, > that newer versions require libfastjson instead of json-c. > > I've already packages libfastjson, and it is available in unstable and > testing [1]. > Before I can switch rsyslog over to use libfastjson, I need a newer > version of liblognorm as well, which as been compiled against > libfastjson. I've been working with rsyslog/liblognorm upstream and the > latest versio 2.0.1 should be ok. > Please consider packaging that version. To test newer rsyslog versions, > I've already updated liblognorm locally and pushed my work to [2]. Feel > free to base your update on that. > Since the library had a soname bump which means going through the NEW > queue, I decided to introduce a new binary package for the lognormalizer > tool to fix #753510. > The git log should be self-explanatory. If you have any questions, > please don't hesitate to ask. > > As the package didn't have a public (Git) repository, I've created a > private on based on the last NMU using git-buildpackage [2]. > Hi Michael, I'm working on the packaging of version 2.0.1, it should be ready soon. I had a look at your repository, it seems you only bumped dependencies, but I got new errors with gcc 6: samp.c: In function ‘ln_sampChkRunawayRule’: samp.c:937:4: error: ignoring return value of ‘fread’, declared with attribute warn_unused_result [-Werror=unused-result] (void)fread(buf, sizeof(char), 1, repo); /* skip '\n' */ ^~~ [...] While it will be easy to fix, I'm surprised you did not had the same. I also had to drop 01-fix-pkgconfig.patch, conflicting, and I think not necessary now. The new binary package is a good idea, I will indeed merge it. When the upload is ready, I will push my repository on alioth to ease collaborative work. Thanks for your patches. Regards, Pierre
Bug#831362: support building libcap-ng without python extensions
On 07/15/2016 01:11 AM, Helmut Grohne wrote: > Source: libcap-ng > Version: 0.7.7-3 > Severity: wishlist > Tags: patch > > Hi, > > libcap-ng is part of the build-closure of essential and thus needs to be > able to be cross built. On the other hand, cross building python > extensions is currenty non-trivial as the python policy is not yet fully > fleshed out wrt cross building. So to make cross building libcap-ng work > today, I am proposing to make those python extensions optional via a > nopython build profile. Refer to > https://lists.debian.org/debian-cross/2016/04/msg4.html for a > rationale on the profile name. > > I am attaching a patch that adds the requested support and I hope that > it is not a big maintenance cost. After applying it, libcap-ng cross > builds just fine under the nopython profile. Please consider applying > it. > Hi Helmut, I have applied your patch and build the package successfully. However, I got a lot of lintian errors related to the profile: Now running lintian... E: libcap-ng source: invalid-profile-name-in-build-profiles-field nopython python-cap-ng E: libcap-ng source: invalid-profile-name-in-build-profiles-field nopython python3-cap-ng W: libcap-ng source: restriction-formula-without-versioned-dpkg-dev-dependency W: libcap-ng source: restriction-formula-with-debhelper-without-debhelper-version E: libcap-ng source: invalid-profile-name-in-source-relation nopython [build-depends: dh-python ] E: libcap-ng source: invalid-profile-name-in-source-relation nopython [build-depends: swig ] E: libcap-ng source: invalid-profile-name-in-source-relation nopython [build-depends: python-all-dev ] E: libcap-ng source: invalid-profile-name-in-source-relation nopython [build-depends: python3-dev ] W: libcap-ng source: restriction-formula-without-versioned-dpkg-dev-dependency W: libcap-ng source: restriction-formula-with-debhelper-without-debhelper-version I am running an up to date sid, but it seems the nopython profile is missing. Is that expected ? Thanks, Pierre
Bug#820002: Should be Multi-Arch: foreign
On 04/04/2016 07:57 PM, Ben Hutchings wrote: > Package: sbsigntool > Version: 0.6-2 > Severity: normal > > It looks like sbsigntool is intended to work cross-architecture, e.g. > an i386 build can operate on an amd64 executable. If this is the > case, please add 'Multi-Arch: foreign' to its control file. > Hi Ben, Maybe I misunderstands 'Multi-Arch: foreign', but the Howto wiki page [1] says that it will allow the package to satisfy the dependency on a different arch. I'm not sure how this will help in that case ? A i386 build should work on any kind of file, but only on a i386 platform. Does that match the 'Foreign' definition ? Pierre [1] https://wiki.debian.org/Multiarch/HOWTO
Bug#819050: Please leave the severity at serious, this bug is a security issue.
On 03/24/2016 09:38 AM, Yves-Alexis Perez wrote: > control: affects -1 suricata > On jeu., 2016-03-24 at 07:20 +0100, Florian Weimer wrote: >> * Hilko Bengen: >> >>> >>> the original report may not have been 100% clear on this, but the bug is >>> the main cause of a vulnerability in Suricata (a network IDS/IPS) that >>> allows for remote denial of service, possibly remote code execution by >>> simply passing crafted packets by a Suricata installation. >> Without the complete test case, that's hard to tell. >> >> If we cannot reproduce this, perhaps Suricata (at least in stable) >> should not explicitly enable the PCRE JIT compiler? > > Adding Pierre (Suricata maintainer) to the loop then. > Hi, Is it the same bug on PCRE that was reported last year ? If so, I have confirmed that it is reproducible in a mail to security@ (<564c6de1.9000...@debian.org>) The bug is in libpcre, see https://lists.exim.org/lurker/message/20140425.115921.793bec64.en.html for details, and http://vcs.pcre.org/pcre?view=revision&revision=1475 for the upstream fix. It indeed affects programs using the JIT feature, that includes suricata. Cheers, Pierre
Bug#815846: ITP: tpm2-tss -- TPM (Trusted Platform Module) 2.0 Software Stack
On Wed, Feb 24, 2016 at 09:08:58PM -0500, Mathieu Trudel-Lapierre wrote: > Package: wnpp > Severity: wishlist > Owner: "Mathieu Trudel-Lapierre" > > * Package name: tpm2-tss > Version : 0.9.8 > Upstream Author : Will Arthur > * URL : https://github.com/01org/TPM2.0-TSS > * License : MIT/BSD > Programming Lang: C, C++ > Description : TPM (Trusted Platform Module) 2.0 Software Stack > > TPM2.0-TSS is a software stack comprising a few layers: > - Feature API (FAPI) > - Enhanced System API (ESAPI) > - System API (SAPI) > - TPM Command Transmission Interface (TCTI) > - Trusted Access Broker/Resource Manager (TAB/RM) > > These are used to interface with TPM chips to provide specific cryptographic > services to the system in a secure manner. > > TPM2.0-TSS is a requirement (for tss2 and tcti) for tpm2-tools (TPM2.0-tools), > for which I will file another ITP. > > It may be relevant here to merge efforts for maintaining TPM tools in a team, > there has been lots of work by pollux in maintaining the trousers stack for > which this project seeks to be an improvement / evolution. > Hi Mathieu, I was indeed intending to package it, since we discussed that during the last TCG meeting in San Francisco. If you are OK to create a team and a project on alioth, I can do it if you want. Regards, Pierre signature.asc Description: PGP signature
Bug#783919: news on ocaml-llvm bindings ?
On Sat, Jan 16, 2016 at 01:56:36PM +0100, Sylvestre Ledru wrote: > Le 11/01/2016 20:56, Pierre Chifflier a écrit : > > tags 783919 +patch > > thanks > > > > On Thu, Nov 26, 2015 at 01:33:19PM +0100, Sylvestre Ledru wrote: > >> I will be happy to apply a patch if you have any. > >> > > Hi Sylvestre, > > > > Here is a patch for llvm-toolchain-3.6. It is now possible to build it > > with the bindings enabled, since ocaml-ctypes >= 0.4 has transitioned > > [1]. > > > I tried to build it for an upload but it failed with: > > debian/rules override_dh_install > make[1]: Entering directory '/tmp/buildd/llvm-toolchain-3.6-3.6.2' > dh_install --fail-missing > dh_install: libllvm-3.6-ocaml-dev missing files: /usr/lib/ocaml/llvm-3.6 > dh_install: missing files, aborting > debian/rules:368: recipe for target 'override_dh_install' failed > make[1]: *** [override_dh_install] Error 2 > > Does it ring a bell? > > Thanks > S > Hi Sylvestre, I'm not sure of the reason, I have built in a clean chroot. This might be caused by something in the build environment. Basically this means that the bindings were not built. You should check (in order): - that you are using the configure version, not the cmake one - that you ocaml packages are up to date (especially ocaml-ctypes, we might want to add a versioned build dependency) - that the patch was applied, especially the debian/rules part (which removes the --disable-bindings and adds --with-ocaml-libdir=...) - that ocaml and libs were correctly detected (this is written at the beginning of config.log) Hope that helps. Cheers, Pierre
Bug#783919: news on ocaml-llvm bindings ?
tags 783919 +patch
thanks
On Thu, Nov 26, 2015 at 01:33:19PM +0100, Sylvestre Ledru wrote:
> I will be happy to apply a patch if you have any.
>
Hi Sylvestre,
Here is a patch for llvm-toolchain-3.6. It is now possible to build it
with the bindings enabled, since ocaml-ctypes >= 0.4 has transitioned
[1].
Basically, besides re-enabling it, I just had to fix the documentation
installdir, and add a patch to fix a wrong use of the ctypes API.
Note that this patch was taken from gentoo [2].
Also, I had to disable the checks (DEB_BUILD_OPTIONS=nocheck).
I have a similar patch for llvm-toolchain-3.7 (without the ctypes patch,
fixed upstream), I will open a separate bug.
Thanks,
Pierre
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792657
[2]
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/llvm/files/llvm-3.6.0-ocaml-ctypes-0.4.0.patch?view=markup
diff -ruN llvm-toolchain-3.6-3.6.2/debian/libllvm-X.Y-ocaml-dev.install.in llvm-toolchain-3.6-3.6.2-ocaml/debian/libllvm-X.Y-ocaml-dev.install.in
--- llvm-toolchain-3.6-3.6.2/debian/libllvm-X.Y-ocaml-dev.install.in 2015-01-14 19:45:58.0 +0100
+++ llvm-toolchain-3.6-3.6.2-ocaml/debian/libllvm-X.Y-ocaml-dev.install.in 2016-01-08 14:39:38.003715195 +0100
@@ -1,2 +1,2 @@
-#@OCAML_STDLIB_DIR@/llvm-@LLVM_VERSION@ @OCAML_STDLIB_DIR@/
-#usr/lib/llvm-@LLVM_VERSION@/docs/llvm/ocamldoc/html usr/share/doc/libllvm-@LLVM_VERSION@-ocaml-dev/
+@OCAML_STDLIB_DIR@/llvm-@LLVM_VERSION@ @OCAML_STDLIB_DIR@/
+usr/lib/llvm-@LLVM_VERSION@/docs/llvm/html usr/share/doc/libllvm-@LLVM_VERSION@-ocaml-dev/
diff -ruN llvm-toolchain-3.6-3.6.2/debian/patches/llvm-3.6.0-ocaml-ctypes-0.4.0.patch llvm-toolchain-3.6-3.6.2-ocaml/debian/patches/llvm-3.6.0-ocaml-ctypes-0.4.0.patch
--- llvm-toolchain-3.6-3.6.2/debian/patches/llvm-3.6.0-ocaml-ctypes-0.4.0.patch 1970-01-01 01:00:00.0 +0100
+++ llvm-toolchain-3.6-3.6.2-ocaml/debian/patches/llvm-3.6.0-ocaml-ctypes-0.4.0.patch 2016-01-08 11:14:03.825228679 +0100
@@ -0,0 +1,35 @@
+diff -Naur llvm-3.6.0.src.orig/bindings/ocaml/executionengine/llvm_executionengine.ml llvm-3.6.0.src/bindings/ocaml/executionengine/llvm_executionengine.ml
+--- llvm-3.6.0.src.orig/bindings/ocaml/executionengine/llvm_executionengine.ml 2015-03-17 11:49:27.274824345 +0100
llvm-3.6.0.src/bindings/ocaml/executionengine/llvm_executionengine.ml 2015-03-17 11:49:40.333829421 +0100
+@@ -43,11 +43,11 @@
+ = "llvm_ee_run_static_dtors"
+ external data_layout : llexecutionengine -> Llvm_target.DataLayout.t
+ = "llvm_ee_get_data_layout"
+-external add_global_mapping_ : Llvm.llvalue -> int64 -> llexecutionengine -> unit
++external add_global_mapping_ : Llvm.llvalue -> nativeint -> llexecutionengine -> unit
+ = "llvm_ee_add_global_mapping"
+-external get_global_value_address_ : string -> llexecutionengine -> int64
++external get_global_value_address_ : string -> llexecutionengine -> nativeint
+ = "llvm_ee_get_global_value_address"
+-external get_function_address_ : string -> llexecutionengine -> int64
++external get_function_address_ : string -> llexecutionengine -> nativeint
+ = "llvm_ee_get_function_address"
+
+ let add_global_mapping llval ptr ee =
+@@ -55,14 +55,14 @@
+
+ let get_global_value_address name typ ee =
+ let vptr = get_global_value_address_ name ee in
+- if Int64.to_int vptr <> 0 then
++ if Nativeint.to_int vptr <> 0 then
+ let open Ctypes in !@ (coerce (ptr void) (ptr typ) (ptr_of_raw_address vptr))
+ else
+ raise (Error ("Value " ^ name ^ " not found"))
+
+ let get_function_address name typ ee =
+ let fptr = get_function_address_ name ee in
+- if Int64.to_int fptr <> 0 then
++ if Nativeint.to_int fptr <> 0 then
+ let open Ctypes in coerce (ptr void) typ (ptr_of_raw_address fptr)
+ else
+ raise (Error ("Function " ^ name ^ " not found"))
diff -ruN llvm-toolchain-3.6-3.6.2/debian/patches/series llvm-toolchain-3.6-3.6.2-ocaml/debian/patches/series
--- llvm-toolchain-3.6-3.6.2/debian/patches/series 2015-09-21 11:14:07.0 +0200
+++ llvm-toolchain-3.6-3.6.2-ocaml/debian/patches/series 2016-01-08 11:14:33.249984884 +0100
@@ -38,3 +38,4 @@
bug783205.patch
bug-24472.diff
bug-790686-build-id.diff
+llvm-3.6.0-ocaml-ctypes-0.4.0.patch
diff -ruN llvm-toolchain-3.6-3.6.2/debian/rules llvm-toolchain-3.6-3.6.2-ocaml/debian/rules
--- llvm-toolchain-3.6-3.6.2/debian/rules 2015-10-20 18:40:08.0 +0200
+++ llvm-toolchain-3.6-3.6.2-ocaml/debian/rules 2015-11-27 17:27:44.294897572 +0100
@@ -207,17 +207,16 @@
--with-optimize-option=' $(opt_flags)' \
--enable-pic \
--enable-libffi \
+ --with-ocaml-libdir=/usr/lib/ocaml/llvm-$(LLVM_VERSION) \
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
--with-binutils-include=/usr/include \
--with-cloog --with-isl \
--with-bug-report-url=http://bugs.debian.org/ \
--enable-shared \
---disable-bindings \
$(CONFIGURE_EXTRA) \
CLANG_VENDOR=$(VENDOR) || { cat config.log tools/polly/config.log; exit 1; }
# cd $(TARGET_BUILD) && cmake ../ -D
Bug#810084: RM: websvn (RoQA; unmaintained, rc-buggy, inactive upstream, alternatives exist)
On 01/06/2016 11:49 AM, Thijs Kinkhorst wrote: > Package: websvn > Severity: serious > > I propose to remove websvn from Debian. > > The package is unmaintained with last maintainer upload in 2011. There was > also > no response to a security issues which I fixed in an NMU one year ago. I then > noticed and reported several packaging issues which have gone unaddressed. > > A bug was upgraded to RC over 200 days ago with no response to date. > > Last upstream release was in 2011. There are several alternatives to this > package. > > I will reassign this bug to ftp-master when no objections arrive 'soon'. > > Cheers, > Thijs > Hi Thijs, websvn is not developed anymore (and I do not use it, which does not help for testing/resolving bugs) since 2011, so I also think the removal is the best option. Cheers, Pierre
Bug#792657: udating ocaml-ctypes ?
block 783919 by 792657 thanks Hi, The OCaml transition [1] seems now complete, which means that the findlib transition (and in turn, the ugrade to ctypes >= 0.4) is possible. Could you consider updating these packages ? I am trying to get the LLVM-OCaml bindings back in Debian [2], but a recent version of ctypes is a hard requirement. Thanks, Pierre [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789133 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783919
Bug#783919: news on ocaml-llvm bindings ?
Hi Sylvestre, Do you have any news on this issue (#783919) ? What are the missing packages, and if there is any hope to have working ocaml-llvm bindings again in Debian ? Building an entire LLVM compiler is really annoying, when I miss only the bindings :/ Cheers, Pierre
Bug#702255: efitools: changing back from ITP to RFP
retitle 702255 ITP: efitools -- Tools to manipulate EFI secure boot keys and signatures owner 702255 ! block 702255 by 702254 thanks Hi, I've finally managed to get some time to work again on this ITP. I've uploaded the sbsigntool package to NEW (See #702254), which is required to build efitools. If/when sbsigntool is accepted, upload for efitools will follow. Pierre
Bug#702254: sbsigntool package
tags 702254 + pending thanks Hi, I finally got some time to work on the package again, and fix it according to the answers from FTPmasters. I'll upload it to NEW. Cheers, Pierre
Bug#783919: libllvm-3.6-ocaml-dev: empty package
Package: libllvm-3.6-ocaml-dev Version: 1:3.6-2 Severity: important Dear Maintainer, The current package libllvm-3.6-ocaml-dev from sid is empty, and does not contain the /usr/lib/ocaml/llvm-3.6/ directory and contents. Regards, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766136: libcap-ng: Python build error, didn't fail build -> empty bindings
severity 766136 normal tags 766136 + moreinfo unreproducible thanks On Tue, Oct 21, 2014 at 07:46:20AM +0100, David Halls wrote: > I tried 'import capng' from Python, failed to import. > Traced the problem down to libcap-ng's build has an error. > See > > https://buildd.debian.org/status/fetch.php?pkg=libcap- > ng&arch=i386&ver=0.7.4-2&stamp=1408698790 > > and search for 'error:'. You'll see > > libtool: relink: gcc -shared -fPIC -DPIC .libs/_capng_la-capng_wrap.o > -lpython2.7 -L/«PKGBUILDDIR»/debian/tmp-python-cap-ng/usr/lib/i386-linux-gnu > -L/usr/lib/i386-linux-gnu -lcap-ng -O2 -Wl,-z -Wl,relro -Wl,-soname > -Wl,_capng.so -o .libs/_capng.so > /usr/bin/ld: cannot find -lcap-ng > >* What exactly did you do (or not do) that was effective (or > ineffective)? > > Rebuilt package on my machine. This works because the .so is already installed > so the -lcap-ng can find it. > Hi, I tried the following tests: - rebuilding libcap-ng: .so is present in the resulting deb - install python-cap-ng (the deb from jessie/sid, not the one from from the previous build) and run python -c 'import capng': no error So it may have been a temporary error, fixed since. I'm just tagging the bug as moreinfo, waiting if you can confirm that the bug is not present for you. Regards, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#783005: suricata: ships embedded libhtp and can conflict with a future libhtp update
On Tue, Apr 21, 2015 at 08:39:16AM +0200, Raphael Hertzog wrote: > Hi, > > On Mon, 20 Apr 2015, Hilko Bengen wrote: > > * Raphaël Hertzog: > > > > > But libhtp is already packaged separately. Embedded copy are best > > > avoided and to me it looks like #777040 got fixed the wrong way. > > > libhtp should be fixed to have a saner SONAME and/or it should > > > generate a strict dependency through its shlibs/symbols files. > > > > Is it your goal to get this fixed in jessie before the release or can > > this wait? > > Well, no, given that the release managers acked the embedded copy in > jessie... but in the long term it's wrong to keep it that way. Hi, [adding Arturo to CC list] Bug #777540 has the history of why libhtp was embedded into the suricata package. In short, the SONAME are updated by every upstream release, forcing a rebuild of all rev-deps each time a new libhtp is uploaded (note that the only rev-dep is suricata). We asked the release team with different solutions, and the chosen was to embed libhtp. Now, I'm a bit confused about what to do now, since there are problems both ways. Arturo: I thought the plan was to keep the current situation, and remove libhtp from Debian ? BR, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772551: Suricata: missing library libhtp-0.5.12.so.1
On Mon, Feb 09, 2015 at 10:42:26PM +0100, Arturo Borrero Gonzalez wrote: > On 9 February 2015 at 15:05, Pierre Chifflier wrote: > > This bug is solved by the next (pending) uploading, to be validated by > > the release team. > > I have a some questions: > > * How this could happen? Aren't these errors supposed to show up on build > logs? > * Why this doesn't seem to affect the version in wheezy-backports? > > I would give suricata a basic autopkgtest support. Hi, This has nothing to do with the override - it is caused by the fact that a newer libhtp was uploader *after* suricata. I think a triggered rebuild of suricata could be enough, but since we are going to upload suricata to close the other bugs, this will also resolve the problem. That mostly means that libhtp must always be uploaded before suricata (and wait for all the buildd to finish building it). Cheers, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772551: Suricata: missing library libhtp-0.5.12.so.1
tags 772551 + pending block 772551 by 777042 thanks Hi, This bug is solved by the next (pending) uploading, to be validated by the release team. The two bug reports for the unblock requests are: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777040 (libhtp) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777042 (suricata) Best regards, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772685: sagan: abandoned package/no longer works
severity 772685 normal thanks Hi, While it's true the packaging is late (mainly due to the fact that upstream completely changed the relation with libee/liblogorm, and that the released versions did not compile because the autotools files were broken), the severity of this bug is absolutely not critical. Thanks, Pierre On Tue, Dec 09, 2014 at 08:30:15PM -0500, westlake wrote: > Package: sagan > Version: 0.2.1.r1-1 > Severity: critical > > The upstream of this package is edition 1.0 while this package > edition on debian is actually quite 2 years out of date. > > bug 681794 here on Jessie/testing appears to be the same as filed > back in 2012 ( > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681794 ) > > It would be great if this package got updated as this software is > still being actively developed. > > thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#768154: unblock: trousers/0.3.13-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package trousers
The recent upload to unstable contains only the targeted fix for the
RC bug reported in #767690.
Full debdiff attached.
unblock trousers/0.3.13-3
diff -Nru trousers-0.3.13/debian/changelog trousers-0.3.13/debian/changelog
--- trousers-0.3.13/debian/changelog 2014-08-20 14:27:34.0 +0200
+++ trousers-0.3.13/debian/changelog 2014-11-04 15:16:06.0 +0100
@@ -1,3 +1,18 @@
+trousers (0.3.13-3) unstable; urgency=high
+
+ * Fix postinst script, preventing installation (Closes: #767690)
+- The postinst script does not fail anymore if the TPM device is not
+ present, or if udev reload command fails.
+ This is typically the case in a chroot environment.
+ * Fix init script to be more robust:
+- Test for TPM device owner and issue a warning if not matching the tss
+ user.
+- Do not try to change uid before running tcsd, the daemon already changes
+ its uid just after starting.
+ * Urgency high, RC bug
+
+ -- Pierre Chifflier Tue, 04 Nov 2014 15:11:08 +0100
+
trousers (0.3.13-2) unstable; urgency=medium
* Fix FTBFS on hurd-i386 and kfreebsd-any (Closes: #754359)
diff -Nru trousers-0.3.13/debian/trousers.init trousers-0.3.13/debian/trousers.init
--- trousers-0.3.13/debian/trousers.init 2012-06-15 12:58:08.0 +0200
+++ trousers-0.3.13/debian/trousers.init 2014-11-04 15:06:24.0 +0100
@@ -35,7 +35,15 @@
exit 0
fi
- start-stop-daemon --start --quiet --oknodo --pidfile /var/run/${NAME}.pid --user ${USER} --chuid ${USER} --exec ${DAEMON} -- ${DAEMON_OPTS}
+ for tpm_dev in /dev/tpm*; do
+ TPM_OWNER=$(stat -c %U $tpm_dev)
+ if [ "x$TPM_OWNER" != "xtss" ]
+ then
+log_warning_msg "TPM device owner for $tpm_dev is not 'tss', this can cause problems."
+ fi
+ done
+
+ start-stop-daemon --start --quiet --oknodo --pidfile /var/run/${NAME}.pid --user ${USER} --exec ${DAEMON} -- ${DAEMON_OPTS}
RETVAL="$?"
log_end_msg $RETVAL
[ "$RETVAL" = 0 ] && pidof $DAEMON > /var/run/${NAME}.pid
diff -Nru trousers-0.3.13/debian/trousers.postinst trousers-0.3.13/debian/trousers.postinst
--- trousers-0.3.13/debian/trousers.postinst 2014-06-29 17:31:52.0 +0200
+++ trousers-0.3.13/debian/trousers.postinst 2014-11-04 14:49:01.0 +0100
@@ -16,9 +16,9 @@
chmod 0700 /var/lib/tpm
# ask udev to check for new udev rules (and fix device permissions)
- if udevadm --version > /dev/null; then
- udevadm control --reload-rules
- udevadm trigger --sysname-match="tpm[0-9]*"
+ if [ -e /dev/tpm0 ] && udevadm --version > /dev/null; then
+ udevadm control --reload-rules ||:
+ udevadm trigger --sysname-match="tpm[0-9]*" ||:
fi
;;
Bug#767690: trousers: fails to install: subprocess installed post-installation script returned error exit status 2
severity 767690 serious tags 767690 - moreinfo unreproducible thanks On Mon, Nov 03, 2014 at 09:45:13PM +0100, Andreas Beckmann wrote: > On 2014-11-03 21:40, Pierre Chifflier wrote: > > I tried for a few days to reproduce the bug on different hosts, without > did you try chroots, not real machines? Yes, except it seems that indeed a recent change to make udev rules reload work with systemd broke the detection. I will set back the severity, sorry for the change. > > > The attached log is also useless, it does not provide any info on the > > failure. Maybe adding set -x to the postinst script could help > > determining if adduser failed (?), or if the udev commands failed. > > probably udev - in the piuparts test chroot no udev is available and > only a minimal set of devices exists (/dev/null and friends) The script needs to reload udev rules, only if at least one device is present, and if udevd is running. I can test easily for devices, but detecting (and sending commands) to udev will probably not work in a chroot :/ I'll try to test the devices, make errors from udev not critical, but test for permissions in the init script. Regards, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767690: trousers: fails to install: subprocess installed post-installation script returned error exit status 2
severity 767690 normal tags 767690 + unreproducible moreinfo thanks Hi, I tried for a few days to reproduce the bug on different hosts, without any luck. I'm therefore lowering the severity to normal, until having more information. Preparing to unpack .../trousers_0.3.13-2_amd64.deb ... Unpacking trousers (0.3.13-2) ... Processing triggers for man-db (2.7.0.1-1) ... Setting up trousers (0.3.13-2) ... root:~# ls -al /dev/tpm0 crw--- 1 tss tss 10, 224 Nov 3 21:28 /dev/tpm0 root:~# ps ax |grep tcs 10173 ?Ss 0:00 /usr/sbin/tcsd The attached log is also useless, it does not provide any info on the failure. Maybe adding set -x to the postinst script could help determining if adduser failed (?), or if the udev commands failed. Regards, Pierre On Sat, Nov 01, 2014 at 10:06:32PM +0100, Andreas Beckmann wrote: > Package: trousers > Version: 0.3.13-2 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package failed to install. As > per definition of the release team this makes the package too buggy for > a release, thus the severity. > > >From the attached log (scroll to the bottom...): > > Selecting previously unselected package trousers. > (Reading database ... 7406 files and directories currently installed.) > Preparing to unpack .../trousers_0.3.13-2_amd64.deb ... > Unpacking trousers (0.3.13-2) ... > Setting up trousers (0.3.13-2) ... > dpkg: error processing package trousers (--configure): >subprocess installed post-installation script returned error exit status 2 > Errors were encountered while processing: >trousers > > > cheers, > > Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754792: libbfio: FTBFS on hurd-386
On Mon, Aug 25, 2014 at 11:15:14AM +0200, Svante Signell wrote: > Attached is also a build dependency on quilt in debian/control. I don't > know if this is strictly needed, but is included for completeness. The > source directory does not have a debian/patches directory since no > patches are present currently. However, the source format is 3.0 > (quilt). > Hi Svante, Thanks for the updated patch, I'm uploading a fixed version. For the record, I did not add a dependency on quilt since it's not necessary when the source format is 3.0 (quilt) (see [1]). Cheers, Pierre [1] https://wiki.debian.org/Projects/DebSrc3.0#Does_a_3.0_.28quilt.29_source_package_need_to_build-depend_on_quilt.3F -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754792: libbfio: FTBFS on hurd-386
On Mon, Jul 14, 2014 at 01:15:26PM +0200, Svante Signell wrote: > Source: libbfio > Version: 20130507-1 > Severity: important > Tags: patch > User: debian-h...@lists.debian.org > Usertags: hurd > > Hello, > > libbfio fails to build from source due to usage of PATH_MAX,which is not > defined on GNU/Hurd. The attached patch fixes usage of PATH_MAX as > second argument to getcwd() by using calls to getcwd (NULL, 0) instead. > Supporting (NULL, 0) as arguments is an extension to POSIX.1-2001 for > libc4, libc5 and glibc, so most modern systems have it. In order to > simplify the patch, only this version is implemented. Hi Svante, I just uploaded new upstream versions for libbfio and libewf. Unfortunately, the patches you sent no longer apply, since the code has changed. I had a quick look, but could not determine what would be the proper way to fix the build on hurd (and probably kfreebsd). If you have some time to look at the new version, it would be great so the package could be fixed before the release. Here are a few more comments/questions on the patch: > Index: libbfio-20130507/libcpath/libcpath_path.c > === > --- libbfio-20130507.orig/libcpath/libcpath_path.c > +++ libbfio-20130507/libcpath/libcpath_path.c > @@ -356,9 +356,6 @@ int libcpath_path_get_current_working_di > } > #if defined( WINAPI ) > *current_working_directory_size = (size_t) _MAX_PATH; > -#else > - *current_working_directory_size = (size_t) PATH_MAX; > -#endif > *current_working_directory = libcstring_narrow_string_allocate( > *current_working_directory_size ); > If I understand correctly, current_working_directory_size is now uninitialized ? Shouldn't it be set to 0 explicitly ? > @@ -387,7 +384,6 @@ int libcpath_path_get_current_working_di > + *current_working_directory = getcwd (NULL, 0); The getcwd manpage says that the allocation of memory is an extension to the POSIX.1-2001 standard, so it seems Linux-specific. Will this cause any problem on other platforms (I suppose Hurd is OK, but what about kFreeBSD ?). Thanks, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736309: libnetfilter-queue serious bug, #736309
Hi Alexandr,
Bug #736309:
libnetfilter-queue-{dev, dbg}: unhandled symlink to directory conversion:
/usr/share/doc/PACKAGE
is marked as serious, and is causing several packages (in my cast,
suricata and nfqueue-bindings) to be scheduled for autoremove.
Do you plan to upload a fixed version ?
Thanks,
Pierre
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738199: Access to the oval generation script ?
Hi, It seems the script to generate OVAL definitions is broken. As the maintainer of openscap, I would like to give a try to update the script and make the definitions work again. Is it possible to access the script ? If so, where ? Thanks, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739485: The package fails to configure in absence of suitable hardware
On Wed, Feb 19, 2014 at 10:05:01AM +0100, Didier Raboud wrote: > Package: trousers > Version: 0.3.11.2-1 > Severity: important > > Unfortunately, trousers doesn't "configure" (in dpkg terms) correctly as > it's init script fails to start with the following error. (I'm using > systemd as init): > Hi, This is probably caused by wrong permissions on the /dev/tpm0 device. There are udev rules in the trousers postinst script: # ask udev to check for new udev rules (and fix device # permissions) if [ -x /etc/init.d/udev ] && pidof udevd > /dev/null; then udevadm control --reload-rules udevadm trigger --sysname-match="tpm[0-9]*" fi So, without any logs, I can only assume that the lines above did not work, for systemd installations. Since I have no systemd install here, and that it works for sysvinit as init, it would be great if someone affected could test the above commands and provide some more details, like checking if /dev/tpm0 exists and belongs to tss:tss. Regards, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680884: [p0f] Please update to v3 [use case]
On Tue, Jan 14, 2014 at 03:51:27PM +0200, Niko Tyni wrote: > On Tue, Apr 23, 2013 at 09:21:39PM +0200, Axel Beckert wrote: > > Chris Knadle wrote: > > > > > I would be really happy if I would be able to use p0f in Debian to > > > > > inform XP users that their OS will be EoL soon. :-) > > > > > > > > For that I needed a package of p0f v3 anyway, so I built one. :-) > > > > > > I've been doing the same elsewhere. ;-) > > Ping? Is there any progress in getting one of these p0f v3 packages into > Debian? The Windows XP EoL date is approaching quickly... > -- Hi, Seems I forgot this package .. Sorry for that. I took my previous packaging files for v3. Basically, the packages is done (conversion to dh 9, etc), it justs needs some testing. I'll upload it to experimental today or in the next few days, and then to unstable. Regards, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735170: RM: wzdftpd -- ROM; buggy, dead upstream
Package: ftp.debian.org Severity: normal Hi, Please remove wzdftpd from Debian. Upstream is dead since a long time, and it has bugs. Regards, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733888: RM: nulog -- ROM; buggy, dead upstream
Package: ftp.debian.org Severity: normal Hi, Please remove nulog from Debian. Upstream is dead since a long time, and it has bugs (including RC) because it does not work with current twisted version. Regards, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733567: cookiecutter: please update to 0.7.0
Package: cookiecutter Version: 0.6.4-1 Severity: wishlist Dear Maintainer, Could you update cookiecutter to the latest upstream version (0.7.0) ? It fixes several bugs and add new features. Thanks, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725945: swig2.0: Missing file swigp4.ml for ocaml bindings
Package: swig2.0 Version: 2.0.10-1 Severity: normal Hi, Since some version (I cannot tell which one precisely, but I think ~ 2.0.8), the file swigp4.ml is not shipped anymore in the ocaml bindings. This file is required and should be added again. Regards, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725670: RM: openscap [kfreebsd-*] -- ROM; ANAIS
Package: ftp.debian.org Severity: normal Hi, Due to some problems with building openscap on kfreebsd-*, I had to upload a new version disabling these architectures. Version 0.9.8-2, currently in unstable, is currently not transitioning because of the old binaries for kfreebsd-* [1]. Can you remove them please ? Thanks, Pierre [1] http://qa.debian.org/excuses.php?package=openscap -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#693892: Still applies to unstable
On Tue, Aug 20, 2013 at 03:23:33PM +0200, gregor herrmann wrote: > On Mon, 12 Aug 2013 16:46:41 +0200, Dominic Hargreaves wrote: > > > This bug still appears to exist in unstable, and since glibc > 2.16 is > > now in unstable, should probably be upgraded. It also blocks the perl > > 5.18 transition which will start soon. > > > > Please could the fix be uploaded to unstable? > > Some investigation: > 1) This seems to be a duplicate of #701412 which claims to be fixed >in 1.0.1-5. > 2) 1.0.1-5 from unstable builds fine for me in a sid and in a >exp+perl5.18 amd64 chroot. > 3) I'd close the bug with this version but would like to check if you >still get the build failure yourself? > Hi, I just uploaded a few minutes ago libprelude 1.0.0-11, built for unstable, with an additional fix for some missing libs in the prelude-admin link phase. Regards, Pierre signature.asc Description: Digital signature
Bug#688172: openscap: Please port to libnl-3.x
On Thu, May 16, 2013 at 12:21:15AM +0200, Michael Biebl wrote: > Hi, > > I'd like to proceed with the removal of libnl1 soon. > > What's the current status of this bug report? > Hi Michael, This is currently in progress, but I need a few more days I think. The package for openscap has been completely rewritten (using debhelper, multiarch etc.) and the changes are pretty big, so I need to test it a bit more before uploading the new packages. Cheers, Pierre signature.asc Description: Digital signature
Bug#680884: [p0f] Please update to v3 [use case]
On Tue, Apr 23, 2013 at 05:23:44PM +0200, Axel Beckert wrote: > Control: tag -1 + patch > > Hi Pierre, Hi Axel, Please give me some time to look at the your package, I have currently only few time because of my work. I may also need to merge your work, as I previously had a git repository with v3, but the packages were never published. That said, I would gladly add you as a co-maintainer if you want to, as I am still interested in the maintenance. Cheers, Pierre > > Axel Beckert wrote on 18-Apr-2013: > > any news on a 3.x p0f version in Debian? The last upload was from > > 2008 and that version doesn't seem to be able to distinguish any > > Windows newer than XP from XP. > > In the meanwhile I could verify that the v3 version can distinguish > between Windows XP and Windows 7/8. :-) Unfortunately the output is > much worse to handle with grep and friends than from v2. :-/ > > > I would be really happy if I would be able to use p0f in Debian to > > inform XP users that their OS will be EoL soon. :-) > > For that I needed a package of p0f v3 anyway, so I built one. :-) > > It's based on the official package as in Debian Unstable, but > completely revamped (e.g. I rewrote debian/rules with debhelper) and > more or less free of lintian-warnings, even with --pedantic. The only > thing lintian (correctly) argues about is, that upstream no more > provides any man-pages. :-( > > I've put a source package and an amd64 package online here: > > http://noone.org/debian/p0f_3.06b-1.dsc (signed) > http://noone.org/debian/p0f_3.06b-1_amd64.deb > http://noone.org/debian/p0f_3.06b-1_amd64.changes (signed and > contains hash sums of p0f_3.06b-1_amd64.deb) > > The .dsc and .changes are signed with my key in the Debian keyring. > > Despite being built in a Sid pbuilder, it works fine on Debian Squeeze > (which is where I need it currently), too. > > Cc'ing the original reporter in case the package helps him for his v3 > use case. > > > P.S.: Please mention if you need or want a co-maintainer for p0f. > > The package mentioned above currently lists you as maintainer and me > as co-maintainer. > > If you're fine with that, I would upload that package to Debian > Experimental -- possibly with some further minor changes. > > For the ease of coordinating joint work on the package, I would > propose a git repository under collab-maint on alioth. (I actually > already have a local git repository for my work on the package so far. > I'd just have to push that somewhere and add Vcs-* headers to the > package.) > > In case you have no more interest in this package, it also would be ok > for me to take over maintenance of the package alone. > > Regards, Axel > -- > ,''`. | Axel Beckert , http://people.debian.org/~abe/ > : :' : | Debian Developer, ftp.ch.debian.org Admin > `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE > `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#702255: ITP: efitools -- Tools to manipulate EFI secure boot keys and signatures
Package: wnpp Severity: wishlist Owner: Pierre Chifflier * Package name: efitools Version : 1.4.0 Upstream Author : James Bottomley * URL : http://blog.hansenpartnership.com/uefi-secure-boot/ * License : GPLv2 Programming Lang: C Description : Tools to manipulate EFI secure boot keys and signatures This package installs a variety of tools for manipulating keys and binary signatures on UEFI secure boot platforms. The tools provide access to the keys and certificates stored in the secure variables of the UEFI firmware, usually in the NVRAM area. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#702254: ITP: sbsigntool -- Utility for signing and verifying files for UEFI Secure Boot
Package: wnpp Severity: wishlist Owner: Pierre Chifflier * Package name: sbsigntool Version : 0.6 Upstream Author : Jeremy Kerr * URL : http://packages.ubuntu.com/quantal/sbsigntool * License : GPL-3+ with OpenSSL exception Programming Lang: C Description : Utility for signing and verifying files for UEFI Secure Boot This package provides utilities that can be used for signing PE programs for use with UEFI Secure Boot, and for verifying the signatures included in the same. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#575358: debian packages for libpff
Hi, I am maintaining the Debian packages for DFF, an open source forensics application and framework. The new version of dff requires a dependency on libpff, and I saw an ITP is already filled (#575358) for it. Since I have some packages ready here, I would like to know if anyone is working on it, or if I can upload the packages to unstable (same as libbfio, set maintainer to the Forensics Team). Cheers, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650842: debian packages for libbfio
Hi Julien, I am maintaining the Debian packages for DFF, an open source forensics application and framework. The new version of dff requires a dependency on libbfio, and I saw you have filled an ITP (#650842) for it. Since it have some packages ready here, I would like to know if you are still working on the packaging, or if we could take these one for an initial upload. If you want, we could co-maintain it (and set the package ownership to the Debian Forensics team). Cheers, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650842: debian packages for libbfio
On Sun, Mar 03, 2013 at 04:17:46PM +0100, Pierre Chifflier wrote: > Hi Julien, > > I am maintaining the Debian packages for DFF, an open source forensics > application and framework. > The new version of dff requires a dependency on libbfio, and I saw you > have filled an ITP (#650842) for it. Since it have some packages ready Err, should read: "Since I have some packages ..." /P > here, I would like to know if you are still working on the packaging, or > if we could take these one for an initial upload. > > If you want, we could co-maintain it (and set the package ownership to > the Debian Forensics team). > > Cheers, > Pierre > > ___ > forensics-devel mailing list > forensics-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700973: unblock: trousers/0.3.9-3+wheezy1
On Thu, Feb 21, 2013 at 08:33:16PM +, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Tue, 2013-02-19 at 23:21 +0100, Pierre Chifflier wrote: > > Please unblock package trousers > > > > Upload 0.3.9-3+wheezy1 fixes a serious bug which causes installation of > > trousers to fail in some cases, when the udev rules are not refreshed > > when triggering the tpm device to setup the correct permissions. > > If it's a serious bug, why is it only "severity: normal"? Well, Lukas Schwaighofer raised the severity in a previous email, but it seems he forgot to CC control. The bug prevents the installation of the package in some case, so should be marked serious imho. Shall I raise the severity ? > > (For future reference, it's appreciated if you file the unblock bug as > the first step in the process, not the last.) > Sorry about this, I thought the packages (especially for unstable) had to be uploaded before filling the unblock request (so I can join the real debdiff). Regards, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700973: unblock: trousers/0.3.9-3+wheezy1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package trousers Upload 0.3.9-3+wheezy1 fixes a serious bug which causes installation of trousers to fail in some cases, when the udev rules are not refreshed when triggering the tpm device to setup the correct permissions. Package in unstable is fixed. Debdiff for testing attached. Thanks, Pierre unblock trousers/0.3.9-3+wheezy1 diff -Nru trousers-0.3.9/debian/changelog trousers-0.3.9/debian/changelog --- trousers-0.3.9/debian/changelog 2012-07-05 20:56:17.0 +0200 +++ trousers-0.3.9/debian/changelog 2013-02-19 22:56:59.0 +0100 @@ -1,3 +1,10 @@ +trousers (0.3.9-3+wheezy1) stable-proposed-updates; urgency=low + + * Reload udev rules before triggering event during postinst +(Closes: #581505) + + -- Pierre Chifflier Mon, 18 Feb 2013 17:29:21 +0100 + trousers (0.3.9-3) unstable; urgency=low * Fix regression introduced in previous patch, preventing removal diff -Nru trousers-0.3.9/debian/trousers.postinst trousers-0.3.9/debian/trousers.postinst --- trousers-0.3.9/debian/trousers.postinst 2012-07-04 21:46:07.0 +0200 +++ trousers-0.3.9/debian/trousers.postinst 2013-02-18 17:31:52.0 +0100 @@ -16,8 +16,10 @@ chmod 0700 /var/lib/tpm # ask udev to check for new udev rules (and fix device permissions) - [ -x /etc/init.d/udev ] && pidof udevd > /dev/null \ - && udevadm trigger --sysname-match="tpm[0-9]*" + if [ -x /etc/init.d/udev ] && pidof udevd > /dev/null; then + udevadm control --reload-rules + udevadm trigger --sysname-match="tpm[0-9]*" + fi ;; abort-upgrade|abort-remove|abort-deconfigure)
Bug#698925: unblock: glpi/0.83.31-2
On Sat, Jan 26, 2013 at 01:39:57PM +0100, Niels Thykier wrote: > Control: tags -1 moreinfo > > On 2013-01-25 18:57, Christian PERRIER wrote: > > Quoting Pierre Chifflier (pol...@debian.org): > > > >> I will indeed remove the files from the source. I just did a minimal > >> diff for the inclusion in testing, to make sure the .swf file is not > >> included in binary packages, and make the source repackaging stuff in a > >> second step. > > > > > > I'm afraid you *have* to repackage to get the package in testing as > > having .swf file without source code might be considered an RC bug > > itself. > > > > Indeed, this would be preferred from the RT PoV as we then only have to > unblock your package once. Hi, I finally had some time to work on a new package, with both removing the extjs library, and fixing the symlink to the library. Since the source is repackaged, I named the new package glpi 0.83.31+dfsg-1 The problem is, the diff is huge (3.5M) due to the removal of the extjs library, so I cannot attach it to this mail. I have attached to this mail a diffstat of the debdiff, and an extract to show all changes not being removals. Can you check the diff and confirm me if this is ok for you ? If you need to complete diff I can of course upload it to a server. If this is fine, what is the next step ? Should I open a new bug for the release team ? Should I also upload the repackaged source in unstable before (or at the same time) ? Thanks, Pierre /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/charts.swf |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/expressinstall.swf |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/box/corners-blue.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/box/corners.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/box/l-blue.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/box/l.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/box/r-blue.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/box/r.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/box/tb-blue.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/box/tb.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/button/arrow.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/button/btn.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/button/group-cs.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/button/group-lr.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/button/group-tb.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/button/s-arrow-b-noline.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/button/s-arrow-b.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/button/s-arrow-bo.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/button/s-arrow-noline.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/button/s-arrow-o.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/button/s-arrow.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/dd/drop-add.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/dd/drop-no.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/dd/drop-yes.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/editor/tb-sprite.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/form/checkbox.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/form/clear-trigger.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/form/clear-trigger.psd |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/form/date-trigger.gif |binary /tmp/9rYllLWBDM/glpi-0.83.31+dfsg/lib/extjs/resources/images/default/form/date-tr
Bug#698925: unblock: glpi/0.83.31-2
On Fri, Jan 25, 2013 at 12:20:36PM +0100, Niels Thykier wrote: > Control: tags -1 moreinfo > > On 2013-01-25 11:51, Pierre Chifflier wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: unblock > > > > Please unblock package glpi > > > > This fixes a security issue, and should allow glpi not to be removed > > from wheezy. > > > > Changelog: > > glpi (0.83.31-2) unstable; urgency=high > > . > >* Security fixes: > > Replace embedded copy of extjs by Debian package, the embedded one > > contains a flash file built with a vulnerable version of yui > > (charts.swf). > > (Closes: #694642) > >* Urgency high, this is a RC bug > > > > Full debdiff attached. > > > > Regards, > > Pierre > > > > unblock glpi/0.83.31-2 > > > > [...] > > Hi, > > Paul Wise suggested that there are no sources for the affected files[1]. > If so, they should be removed from the source package[2]. > Hi, I will indeed remove the files from the source. I just did a minimal diff for the inclusion in testing, to make sure the .swf file is not included in binary packages, and make the source repackaging stuff in a second step. Regards, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698925: unblock: glpi/0.83.31-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package glpi
This fixes a security issue, and should allow glpi not to be removed
from wheezy.
Changelog:
glpi (0.83.31-2) unstable; urgency=high
.
* Security fixes:
Replace embedded copy of extjs by Debian package, the embedded one
contains a flash file built with a vulnerable version of yui
(charts.swf).
(Closes: #694642)
* Urgency high, this is a RC bug
Full debdiff attached.
Regards,
Pierre
unblock glpi/0.83.31-2
-- System Information:
Debian Release: 6.0.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32.55.pollux-grsec (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru glpi-0.83.31/debian/changelog glpi-0.83.31/debian/changelog
--- glpi-0.83.31/debian/changelog 2012-07-22 21:47:52.0 +0200
+++ glpi-0.83.31/debian/changelog 2013-01-25 11:37:11.0 +0100
@@ -1,3 +1,13 @@
+glpi (0.83.31-2) unstable; urgency=high
+
+ * Security fixes:
+Replace embedded copy of extjs by Debian package, the embedded one
+contains a flash file built with a vulnerable version of yui (charts.swf).
+(Closes: #694642)
+ * Urgency high, this is a RC bug
+
+ -- Pierre Chifflier Fri, 25 Jan 2013 11:37:09 +0100
+
glpi (0.83.31-1) unstable; urgency=medium
* Imported Upstream version 0.83.31
diff -Nru glpi-0.83.31/debian/control glpi-0.83.31/debian/control
--- glpi-0.83.31/debian/control 2012-03-10 11:37:14.0 +0100
+++ glpi-0.83.31/debian/control 2013-01-25 11:32:56.0 +0100
@@ -15,6 +15,7 @@
ttf-freefont,
tinymce,
libphp-phpmailer,
+libjs-extjs,
${misc:Depends}
Description: IT and Asset management software
GLPI stands for "Gestionnaire libre de parc informatique",
diff -Nru glpi-0.83.31/debian/rules glpi-0.83.31/debian/rules
--- glpi-0.83.31/debian/rules 2012-04-28 16:58:14.0 +0200
+++ glpi-0.83.31/debian/rules 2013-01-25 11:34:15.0 +0100
@@ -67,6 +67,8 @@
rm -rf $(DESTDIR)/usr/share/glpi/lib/phpcas
rm -rf $(DESTDIR)/usr/share/glpi/lib/tiny_mce
rm -rf $(DESTDIR)/usr/share/glpi/lib/phpmailer
+ rm -rf $(DESTDIR)/usr/share/glpi/lib/extjs; \
+ ln -s /usr/share/javascript/extjs $(DESTDIR)/usr/share/glpi/lib/extjs
build-arch: build
build-indep: build
Bug#697512: trousers: incompatible licenses (trousers GPLv2+ / libtspi1 CPL)
On Sun, Jan 06, 2013 at 02:05:21PM +0100, Andreas Metzler wrote: > Package: trousers > Version: 0.3.10-1 > > Hello, > > afaict the binaries in the trousers package are not distributable. They > are GPLv2+ licensed but link against against a CPL library (libtspi1). > According to http://www.gnu.org/licenses/license-list.html (and > wikipedia) CPL is not compatible with GPL. > > cu andreas > Hi, I checked and it seems that only files under the tools/ directory are licensed under GPLv2+, the others are CPL. So if licenses are indeed incompatible that should not affect the entire package but only the optional tools. I will remove them in a future upload. Cheers, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#692649: trousers: CVE-2012-0698
> > Sorry for the late reply. This seems to have fallen through the cracks > and I'm currently catching up with old mail. > > I think this doesn't warrant a DSA, but could you fix this through > a stable point update? > http://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable > > (Adding Jonathan, the stable point update security coordinator to CC) > Hi Moritz, This CVE (CVE-2012-0698) has already been closed by an upload on November 27th, acked by Yves-Alexis Perez (see [1] for history), so trousers is now fixed for all versions in Debian. Cheers, Pierre [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692649 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#692649: [Fwd: Bug#692649: trousers: CVE-2012-0698]
On Sat, Nov 17, 2012 at 03:00:04PM +0100, Yves-Alexis Perez wrote: > On sam., 2012-11-17 at 11:30 +0100, Pierre Chifflier wrote: > > Hi Security Team, > > > > I'm forwarding this email to ask for review on the correction for > > CVE-2012-0698 in stable (other versions are not affected). > > > Hey, > > is the fixed package robust against the python script and did you test > if it didn't break anything? Hi, I've basically tested the package (running tpm_info), so far it seems ok. The server does not crash anymore on the python script. > > This comment (https://bugzilla.redhat.com/show_bug.cgi?id=781648#c12) > from the redhat bug is a bit concerning, although I'm not sure to what > it's referring too. > That is the upstream fix I have included. I think the comments is related to the fact that, while it does fix the crash from the python script, there may be concerns from other possible functions affected by the same problem. None seems to have happened since this fix, so I think it's ok to include it in stable, and testing/sid have newer versions. Regards, Pierre signature.asc Description: Digital signature
Bug#692268: vym: Cannot add accented characters to mind map
tags 692268 + unreproducible thanks On Sun, Nov 04, 2012 at 01:44:43PM +0100, Bruno Filipe Oliveira Ramos wrote: > Package: vym > Version: 2.3.3-1 > Severity: important > Tags: l10n > > Dear Maintainer, > > there seems to be a problem when adding accented characters to the mind map. > If you type the accented characters using the keyboard the accent will be > added > separately from the character. For example if you try to type é you get ´e. > However, if you copy paste the character directly to the mind map it works OK. Hi, I cannot reproduce this problem: after creating a new mind map, I can enter accented letters (é è à) without any particular problem. This could be related to locale, however my setup seems similar to yours (LANG=en_US.UTF-8 LC_ALL=). Can you check that this is specific to vym, and not found in other Qt applications ? Regards, Pierre > > Best regards, > > Bruno > > > > -- System Information: > Debian Release: wheezy/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, > 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages vym depends on: > ii libc6 2.13-36 > ii libgcc1 1:4.7.2-4 > ii libqt4-dbus 4:4.8.2+dfsg-2 > ii libqt4-network 4:4.8.2+dfsg-2 > ii libqt4-svg 4:4.8.2+dfsg-2 > ii libqt4-xml 4:4.8.2+dfsg-2 > ii libqtcore4 4:4.8.2+dfsg-2 > ii libqtgui4 4:4.8.2+dfsg-2 > ii libstdc++6 4.7.2-4 > ii unzip 6.0-7 > ii xsltproc1.1.26-14 > ii zip 3.0-6 > > vym recommends no packages. > > Versions of packages vym suggests: > ii ruby 4.9 > ii ruby1.8 [ruby-interpreter]1.8.7.358-6 > ii ruby1.9.1 [ruby-interpreter] 1.9.3.194-3 > > -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#692649: trousers: CVE-2012-0698
On Thu, Nov 08, 2012 at 08:03:35AM +0100, Moritz Muehlenhoff wrote:
> Package: trousers
> Severity: grave
> Tags: security
> Justification: user security hole
>
> Please see here for details:
> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-0698
>
> Cheers,
> Moritz
>
Hi Moritz,
I have tested with the python script referenced in the sourceforge
ticket [1], and testing/unstable version is not affected.
Version in squeeze seems affected, so I have prepared an upload with the
fix from upstream [2]. I am attaching the diff to this email, can you
confirm me if it is fine, and if I can upload it ?
Regards,
Pierre
[1]
http://sourceforge.net/tracker/index.php?func=detail&aid=3473554&group_id=126012&atid=704358
[2]
http://trousers.git.sourceforge.net/git/gitweb.cgi?p=trousers/trousers;a=commit;h=ae0c2f8c1fd7a96ba0191f83b6057f8cbc51e786
diff -Nru trousers-0.3.5/debian/changelog trousers-0.3.5/debian/changelog
--- trousers-0.3.5/debian/changelog 2010-07-12 10:46:22.0 +0200
+++ trousers-0.3.5/debian/changelog 2012-11-08 22:17:25.0 +0100
@@ -1,3 +1,10 @@
+trousers (0.3.5-2+squeeze1) stable-security; urgency=high
+
+ * Fix crash when malformed packet is received (CVE-2012-0698)
+Closes: #692649
+
+ -- Pierre Chifflier Thu, 08 Nov 2012 22:08:58 +0100
+
trousers (0.3.5-2) unstable; urgency=low
* QA upload.
diff -Nru trousers-0.3.5/debian/patches/04-security-cve-2012-0698.patch trousers-0.3.5/debian/patches/04-security-cve-2012-0698.patch
--- trousers-0.3.5/debian/patches/04-security-cve-2012-0698.patch 1970-01-01 01:00:00.0 +0100
+++ trousers-0.3.5/debian/patches/04-security-cve-2012-0698.patch 2012-11-08 22:17:16.0 +0100
@@ -0,0 +1,252 @@
+From ae0c2f8c1fd7a96ba0191f83b6057f8cbc51e786 Mon Sep 17 00:00:00 2001
+From: Rajiv Andrade
+Date: Tue, 17 Jan 2012 15:32:42 -0200
+Subject: [PATCH 1/1] TCSD robustness
+
+Included a set of boundary checks to increase TCSD robustness.
+
+Signed-off-by: Rajiv Andrade
+---
+ src/include/rpc_tcstp.h |2 +-
+ src/include/rpc_tcstp_tcs.h |4 ++--
+ src/include/tcs_tsp.h |5 +
+ src/include/tcs_utils.h |5 -
+ src/tcs/rpc/tcstp/rpc.c | 15 ++-
+ src/tcs/tcs_pbg.c |9 +
+ src/tcs/tcs_utils.c |4 ++--
+ src/tcsd/tcsd_threads.c |2 +-
+ src/tspi/rpc/tcstp/rpc.c| 12 ++--
+ 9 files changed, 36 insertions(+), 22 deletions(-)
+
+diff --git a/src/include/rpc_tcstp.h b/src/include/rpc_tcstp.h
+index ed79911..50859e2 100644
+--- a/src/include/rpc_tcstp.h
b/src/include/rpc_tcstp.h
+@@ -31,7 +31,7 @@ struct tcsd_packet_hdr {
+
+ struct tcsd_comm_data {
+ BYTE *buf;
+- int buf_size;
++ UINT32 buf_size;
+ struct tcsd_packet_hdr hdr;
+ } STRUCTURE_PACKING_ATTRIBUTE;
+
+diff --git a/src/include/rpc_tcstp_tcs.h b/src/include/rpc_tcstp_tcs.h
+index 9f32814..57eab27 100644
+--- a/src/include/rpc_tcstp_tcs.h
b/src/include/rpc_tcstp_tcs.h
+@@ -392,8 +392,8 @@ void LoadBlob_LOADKEY_INFO(UINT64 *, BYTE *, TCS_LOADKEY_INFO *);
+ void UnloadBlob_LOADKEY_INFO(UINT64 *, BYTE *, TCS_LOADKEY_INFO *);
+ void LoadBlob_PCR_EVENT(UINT64 *, BYTE *, TSS_PCR_EVENT *);
+ TSS_RESULT UnloadBlob_PCR_EVENT(UINT64 *, BYTE *, TSS_PCR_EVENT *);
+-int setData(TCSD_PACKET_TYPE, int, void *, int, struct tcsd_comm_data *);
+-UINT32 getData(TCSD_PACKET_TYPE, int, void *, int, struct tcsd_comm_data *);
++int setData(TCSD_PACKET_TYPE, unsigned int, void *, int, struct tcsd_comm_data *);
++UINT32 getData(TCSD_PACKET_TYPE, unsigned int, void *, int, struct tcsd_comm_data *);
+ void initData(struct tcsd_comm_data *, int);
+ int recv_from_socket(int, void *, int);
+ int send_to_socket(int, void *, int);
+diff --git a/src/include/tcs_tsp.h b/src/include/tcs_tsp.h
+index bba3258..fdca21e 100644
+--- a/src/include/tcs_tsp.h
b/src/include/tcs_tsp.h
+@@ -90,4 +90,9 @@ struct key_disk_cache
+ /* needed by execute transport in the TSP */
+ #define TSS_TPM_TXBLOB_HDR_LEN (sizeof(UINT16) + (2 * sizeof(UINT32)))
+
++#define TSS_TPM_TXBLOB_SIZE (4096)
++#define TSS_TXBLOB_WRAPPEDCMD_OFFSET (TSS_TPM_TXBLOB_HDR_LEN + sizeof(UINT32))
++#define TSS_MAX_AUTHS_CAP (1024)
++#define TSS_REQ_MGR_MAX_RETRIES (5)
++
+ #endif
+diff --git a/src/include/tcs_utils.h b/src/include/tcs_utils.h
+index 71cf3f7..0f0f4ce 100644
+--- a/src/include/tcs_utils.h
b/src/include/tcs_utils.h
+@@ -92,11 +92,6 @@ TSS_RESULT owner_evict_init();
+ #define EVENT_LOG_final()
+ #endif
+
+-#define TSS_TPM_TXBLOB_SIZE (4096)
+-#define TSS_TXBLOB_WRAPPEDCMD_OFFSET (TSS_TPM_TXBLOB_HDR_LEN + sizeof(UINT32))
+-#define TSS_MAX_AUTHS_CAP (1024)
+-#define TSS_REQ_MGR_MAX_RETRIES (5)
+-
+ #define next( x ) x = x->next
+
+ TSS_RESULT key_mgr_dec_ref_count(TCS_KEY_HANDLE);
+diff --git a/src/tcs/rpc/tcstp/rpc.c b/src/tcs/rpc/tcstp/rpc.c
+index ca1a4df..849f652 100644
+--- a/src/tcs/rpc/tcstp/rpc.c
b/src/tcs/rpc/tcstp/rpc.c
+@@ -181,7 +18
Bug#689417: opencryptoki: CVE-2012-4454 CVE-2012-4455
On Tue, Oct 30, 2012 at 06:21:07PM +0100, Moritz Muehlenhoff wrote: > On Sun, Oct 21, 2012 at 10:57:38PM +0200, Arthur de Jong wrote: > > On Tue, 2012-10-02 at 14:37 +0200, Moritz Muehlenhoff wrote: > > > Please see the thread starting at > > > http://www.openwall.com/lists/oss-security/2012/09/07/2 > > > for details. > > > > I've had a quick look at this bug to see if it can be fixed in Debian. > > There are four patches referenced in the thread (I haven't verified if > > there are more patches required): > > > > - > > http://opencryptoki.git.sourceforge.net/git/gitweb.cgi?p=opencryptoki/opencryptoki;a=commitdiff;h=b7fcb3eb0319183348f1f4fb90ede4edd6487c30 > > 32 files changed, 182 insertions(+), 1166 deletions(-) > > This change is huge and mainly seems to be quivalent to setting > > SPINXPL as defined and ensuring SYSVSEM isn't. There are however a few > > other changes in there which may be due to the removal of the > > compatibility code. > > This patch doesn't apply cleanly to 2.3.1 in Debian but I've managed > > to manually fix it (attached is a version if anyone is interested). > > - > > http://opencryptoki.git.sourceforge.net/git/gitweb.cgi?p=opencryptoki/opencryptoki;a=commitdiff;h=58345488c9351d9be9a4be27c8b407c2706a33a9 > > 31 files changed, 2975 insertions(+), 280 deletions(-) > > Lots of changes in the tests but it also seems to contain some > > cleanups related to the previous change, a change from lock_shm() to > > XProcLock(), some moving of locks to /var/lock and a few other > > changes. > > - > > http://opencryptoki.git.sourceforge.net/git/gitweb.cgi?p=opencryptoki/opencryptoki;a=commitdiff;h=8a63b3b17d34718d0f8c7525f93b5eb3c623076a > > 23 files changed, 449 insertions(+), 99 deletions(-) > > Includes a FAQ typo fix and the introduction of a lot of new code. > > - > > http://opencryptoki.git.sourceforge.net/git/gitweb.cgi?p=opencryptoki/opencryptoki;a=commitdiff;h=5667edb52cd27b7e512f48f823b4bcc6b872ab15 > > 1 files changed, 3 insertions(+), 3 deletions(-) > > Very small change in the Makfile which creates the lock directory. > > Should not be relevant for Debian because subdirectories of /var/lock > > should be created on the fly. > > > > The changes are huge and can probably not be easily backported to > > Debian's 2.3.1. A few other options come to mind: > > - see if upstream can provide patches for 2.3.1 > > - see if the necessary fixes can be made some other way > > - upgrade to upstream 2.4.2 > > - remove from wheezy > > (the only reverse dependency for opencryptoki seems to be tpm-tools) > > > > Anyway, I don't think I can do much more for this bug because I'm afraid > > it will take a little more time than I have available at the moment. I > > was having a look and I though I would just add my notes to the bug log. > > > > Good luck with this bug! ;) > > Removing opencryptoki from Wheezy seems best to me. We should't keep > outdated crypto toolkits without an active maintainer in the archive. > > CCing the Pierre, the tpm-tools maintainer to see, whether tpm-tools > is usable withput opencryptoki or whether he's interested in adopting > it himself. > Hi, IMHO the best solution would be to upgrade opencryptoki, including Wheezy. Trying to backport many patches will be complex to maintain and will create a version that could be very different from upstream, leading to bugs (on functionalities, and security). tpm-tools can be compiled without opencryptoki, but this would disable the pkcs#11 support and so loose some functionalities. Except the dependency in debian/control, there should not be any other changes to be done. Cheers, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682482: unblock: glpi/0.83.31-1
On Mon, Jul 30, 2012 at 02:49:50PM +0200, Niels Thykier wrote: > On 2012-07-23 10:56, Pierre Chifflier wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: unblock > > > > Hi, > > > > GLPI 0.83.31 (micro-fix based on 0.83.3) is an important security > > release, fixing two CVEs: > > > > CVE-2012-4002: > > Bug #3704: CSRF prevention step 1 > > Bug #3707: CSRF prevention step 2 > > > > CVE-2012-4003: > > Bug #3705: Security XSS for few items > > > > https://forge.indepnet.net/projects/glpi/versions/771 > > > > Note: the diff from 0.83.2-1 (current testing) is pretty big, but almost > > all the patch is made of fixes in many files. Trying to backport would > > make no sense imho since it would bring almost everything, and make future > > maintenance even harder. > > > > Please allow GLPI 0.83.31 in testing. > > > > Regards, > > Pierre > > > > unblock glpi/0.83.31-1 > > > > > > Hi, > > I am afraid that diff is too much for me to review. I have tried a > couple of times now and there is lot in there I expect is "unrelated > changes". > > I understand that due to #3707, the security fix only will still be a > huge diff. That said, it is not the Html::closeForm() (i.e. CSRF step > 2) that I choke on. So I would be would be interested in seening the > diff with only the security fixes. > > ~Niels > > Hi, I agree that the diff is pretty big, and that splitting only the security fixes is hard (and would make maintenance almost impossible). I used a few commands to extract a "trimmed" version of the patch: git df upstream/0.83.2..upstream/0.83.31 > glpi_0.83.31_raw.diff cat glpi_0.83.31_raw.diff | filterdiff -x '*locales*' -x '*htmlawed*' \ -x '*glpi-0.83.1-empty.sql*' -x '*update*' > glpi_0.83.31_filtered.diff to exclude the changes related to locales and similar. I did not attach the patch to this mail, it is still 200kB. The stripped diff still makes 5300 lines out of the ~9000 original. It also appears that it does not only include calls to Html::closeForm() but also checks on HTTP_REFERRER (and exemption on some pages with DO_NOT_CHECK_HTTP_REFERER), and addition of CURRENTCSRFTOKEN. I know that there are rules for the freeze, but I do not feel many choices here: - keep a vulnerable version for wheezy. Not good. I may try to maintain something in -backports, but that would still mean having a vulnerable version by default. - try to backport only the security corrections in the current version in testing. Honestly, I do not think I will be able to do that, so if this is decided I will ask for some help. Additionally, since the submission of this ticket, version 0.83.4 was released with some new fixes (not tagged as security, but #3800 also concerns HTTP_REFERER for ex.). Regards, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682482: unblock: glpi/0.83.31-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, GLPI 0.83.31 (micro-fix based on 0.83.3) is an important security release, fixing two CVEs: CVE-2012-4002: Bug #3704: CSRF prevention step 1 Bug #3707: CSRF prevention step 2 CVE-2012-4003: Bug #3705: Security XSS for few items https://forge.indepnet.net/projects/glpi/versions/771 Note: the diff from 0.83.2-1 (current testing) is pretty big, but almost all the patch is made of fixes in many files. Trying to backport would make no sense imho since it would bring almost everything, and make future maintenance even harder. Please allow GLPI 0.83.31 in testing. Regards, Pierre unblock glpi/0.83.31-1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680343: unblock: trousers/0.3.9-2
On Sat, Jul 21, 2012 at 12:23:03PM +0200, Julien Cristau wrote: > On Thu, Jul 5, 2012 at 21:25:38 +0200, Pierre Chifflier wrote: > > > +# kill tcsd (and any other process owned by the tss user) > > +killall -u tss 2>/dev/null || true > > Why is this necessary, and what happens if psmisc isn't installed? > Hi Julien, This is used to kill the daemon if the process is running, and avoid that two processes try to access /dev/tpm0 on the next start. If the command fails, or if psmisc is not installed, the script should continue to allow the upgrade. The next start of the init script will run a second daemon, which will stop (EBUSY). A second restart should work, since the init script will be fixed after. Cheers, Pierre signature.asc Description: Digital signature
Bug#680343: unblock: trousers/0.3.9-2
On Thu, Jul 05, 2012 at 09:17:59PM +0200, Pierre Chifflier wrote:
>
> I've attached a full debdiff (modifications of both packages).
>
Here it is
diff -Nru trousers-0.3.9/debian/changelog trousers-0.3.9/debian/changelog
--- trousers-0.3.9/debian/changelog 2012-06-18 22:22:21.0 +0200
+++ trousers-0.3.9/debian/changelog 2012-07-05 20:56:17.0 +0200
@@ -1,3 +1,17 @@
+trousers (0.3.9-3) unstable; urgency=low
+
+ * Fix regression introduced in previous patch, preventing removal
+(Closes: #680375)
+
+ -- Pierre Chifflier Thu, 05 Jul 2012 20:56:13 +0200
+
+trousers (0.3.9-2) unstable; urgency=low
+
+ * Add workaround for upgrade failure for versions before 0.3.8-3
+(Closes: #679621)
+
+ -- Pierre Chifflier Wed, 04 Jul 2012 21:57:22 +0200
+
trousers (0.3.9-1) unstable; urgency=low
* Imported Upstream version 0.3.9
diff -Nru trousers-0.3.9/debian/trousers.postinst trousers-0.3.9/debian/trousers.postinst
--- trousers-0.3.9/debian/trousers.postinst 2012-02-26 11:47:51.0 +0100
+++ trousers-0.3.9/debian/trousers.postinst 2012-07-04 21:46:07.0 +0200
@@ -5,7 +5,7 @@
case "${1}" in
configure)
# Adding tss system user
- adduser --system --home /var/lib/tpm --shell /bin/false --no-create-home --group tss
+ adduser --system --quiet --home /var/lib/tpm --shell /bin/false --no-create-home --group tss
# Setting owner
chown tss:tss /var/lib/tpm -R
diff -Nru trousers-0.3.9/debian/trousers.prerm trousers-0.3.9/debian/trousers.prerm
--- trousers-0.3.9/debian/trousers.prerm 1970-01-01 01:00:00.0 +0100
+++ trousers-0.3.9/debian/trousers.prerm 2012-07-05 20:48:17.0 +0200
@@ -0,0 +1,45 @@
+#!/bin/sh
+# prerm script for trousers
+#
+# see: dh_installdeb(1)
+
+set -e
+
+# summary of how this script can be called:
+#* `remove'
+#* `upgrade'
+#* `failed-upgrade'
+#* `remove' `in-favour'
+#* `deconfigure' `in-favour'
+#`removing'
+#
+# for details, see http://www.debian.org/doc/debian-policy/ or
+# the debian-policy package
+
+
+case "$1" in
+remove|upgrade|deconfigure)
+;;
+
+failed-upgrade)
+if dpkg --compare-versions "$2" lt 0.3.8-3; then
+# hack to avoid #676828
+# removing the executable will make the init script exit gracefully
+rm -f /usr/sbin/tcsd
+# kill tcsd (and any other process owned by the tss user)
+killall -u tss 2>/dev/null || true
+fi
+;;
+
+*)
+echo "prerm called with unknown argument \`$1'" >&2
+exit 1
+;;
+esac
+
+# dh_installdeb will replace this with shell code automatically
+# generated by other debhelper scripts.
+
+#DEBHELPER#
+
+exit 0
Bug#680343: unblock: trousers/0.3.9-2
On Thu, Jul 05, 2012 at 10:01:08AM +0200, Pierre Chifflier wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package trousers > > This version fixes an annoying bug which prevents upgrades or removal > from previous versions, including stable (and thus makes upgrades fail, > without any proper way to upgrade or remove the old version). > See #67682 and #679621 > > The fix is a workaround: since the init script cannot be used, we kill > and remove the executable in the prerm script so the init script can > exit properly, and continue the upgrade process with the new version. Hi, The previous upload was b0rked, it introduced a regression (upgrade was working, removal broke, causing #680375). I have uploaded a new version fixing both bugs (tested for install, upgrade, and removal). I've attached a full debdiff (modifications of both packages). Sorry for the wrong upload. unblock trousers/0.3.9-3 Cheers, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680343: unblock: trousers/0.3.9-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package trousers
This version fixes an annoying bug which prevents upgrades or removal
from previous versions, including stable (and thus makes upgrades fail,
without any proper way to upgrade or remove the old version).
See #67682 and #679621
The fix is a workaround: since the init script cannot be used, we kill
and remove the executable in the prerm script so the init script can
exit properly, and continue the upgrade process with the new version.
debdiff attached
Thanks,
Pierre
unblock trousers/0.3.9-2
diff -Nru trousers-0.3.9/debian/changelog trousers-0.3.9/debian/changelog
--- trousers-0.3.9/debian/changelog 2012-06-18 22:22:21.0 +0200
+++ trousers-0.3.9/debian/changelog 2012-07-04 21:57:25.0 +0200
@@ -1,3 +1,10 @@
+trousers (0.3.9-2) unstable; urgency=low
+
+ * Add workaround for upgrade failure for versions before 0.3.8-3
+(Closes: #679621)
+
+ -- Pierre Chifflier Wed, 04 Jul 2012 21:57:22 +0200
+
trousers (0.3.9-1) unstable; urgency=low
* Imported Upstream version 0.3.9
diff -Nru trousers-0.3.9/debian/trousers.postinst trousers-0.3.9/debian/trousers.postinst
--- trousers-0.3.9/debian/trousers.postinst 2012-02-26 11:47:51.0 +0100
+++ trousers-0.3.9/debian/trousers.postinst 2012-07-04 21:46:07.0 +0200
@@ -5,7 +5,7 @@
case "${1}" in
configure)
# Adding tss system user
- adduser --system --home /var/lib/tpm --shell /bin/false --no-create-home --group tss
+ adduser --system --quiet --home /var/lib/tpm --shell /bin/false --no-create-home --group tss
# Setting owner
chown tss:tss /var/lib/tpm -R
diff -Nru trousers-0.3.9/debian/trousers.prerm trousers-0.3.9/debian/trousers.prerm
--- trousers-0.3.9/debian/trousers.prerm 1970-01-01 01:00:00.0 +0100
+++ trousers-0.3.9/debian/trousers.prerm 2012-07-04 21:46:07.0 +0200
@@ -0,0 +1,42 @@
+#!/bin/sh
+# prerm script for trousers
+#
+# see: dh_installdeb(1)
+
+set -e
+
+# summary of how this script can be called:
+#* `remove'
+#* `upgrade'
+#* `failed-upgrade'
+#* `remove' `in-favour'
+#* `deconfigure' `in-favour'
+#`removing'
+#
+# for details, see http://www.debian.org/doc/debian-policy/ or
+# the debian-policy package
+
+
+case "$1" in
+failed-upgrade)
+if dpkg --compare-versions "$2" lt 0.3.8-3; then
+# hack to avoid #676828
+# removing the executable will make the init script exit gracefully
+rm -f /usr/sbin/tcsd
+# kill tcsd (and any other process owned by the tss user)
+killall -u tss 2>/dev/null || true
+fi
+;;
+
+*)
+echo "prerm called with unknown argument \`$1'" >&2
+exit 1
+;;
+esac
+
+# dh_installdeb will replace this with shell code automatically
+# generated by other debhelper scripts.
+
+#DEBHELPER#
+
+exit 0
Bug#631807: segfault in libcap-ng0 is back on armel - filecap , bluetoothd etc
Hi, I have merged the patch from Alban Browaeys (thanks to him for writing it) in version 0.6.6-2, just uploaded a few moments ago. Thanks, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#647946: Fails to install on squeeze
fixed 647946 1.0.0-2 close 647946 thanks Hi, The installation fails because the profile for prelude-lml does not exist. The bug was fixed after Squeeze (See #616178) and documented in the README.Debian file: Profile --- A Prelude profile must be created for prelude-lml. To create it, run (as root):: prelude-admin register "prelude-lml" "idmef:w" --uid 0 --gid 0 Unfortunately, a new package cannot be uploaded to squeeze as it is the stable version (and due to the Debian policy). As a workaround, creating the profile before installing the package works. As this issue is fixed in the existing version of the package, I'm closing this bug. Regards, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#673509: RM: esvn -- ROM; dead upstream, uses qt3
Package: ftp.debian.org Severity: normal Hi, Please remove esvn from unstable. Upstream is dead since 2010, and there is no Qt4 version. Thanks, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671042: paxctl: Please upgrade to version 0.7
Package: paxctl Version: 0.6-1 Severity: normal Hi, Upstream version 0.7 was released for a while now, and fixes some problems with the -C option. Please upgrade to version 0.7, available at http://pax.grsecurity.net/paxctl-0.7.tar.bz2 Cheers, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666330: suricata: FTBFS: cp: cannot stat `debian/tmp/suricata-debian.yaml': No such file or directory
tags 666330 + moreinfo unreproducible severity 666330 normal thanks On Fri, Mar 30, 2012 at 11:21:15AM +0200, Lucas Nussbaum wrote: > Source: suricata > Version: 1.2.1-1 > Severity: serious > Tags: wheezy sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20120330 qa-ftbfs qa-ftbfs-buildarch > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. > > This rebuild was done by building only architecture:any binary packages > (binary-arch target of debian/rules), and using a recent dpkg that uses the > build-arch target if available. > Also, only the Build-Depends were installed, not the Build-Depends-Indep. Hi Lucas, I tried for some time to reproduce the problem, without success - I may be missing something here. apt-get source suricata + apt-get build-dep suricata => works The only difference I have in the build-logs is that the dh_install line does not mention the same directory (you have debian/tmp/suricata-debian.yaml, while I get ./suricata-debian.yaml). Any idea ? > > Relevant part: > > make[3]: Entering directory `/«PKGBUILDDIR»' > > make[3]: Nothing to be done for `install-exec-am'. > > make[3]: Nothing to be done for `install-data-am'. > > make[3]: Leaving directory `/«PKGBUILDDIR»' > > make[2]: Leaving directory `/«PKGBUILDDIR»' > > make[1]: Leaving directory `/«PKGBUILDDIR»' > >dh_install -a > > cp -a debian/tmp/suricata-debian.yaml debian/suricata//etc/suricata/ > > cp: cannot stat `debian/tmp/suricata-debian.yaml': No such file or directory > > dh_install: cp -a debian/tmp/suricata-debian.yaml > > debian/suricata//etc/suricata/ returned exit code 1 > > make: *** [binary-arch] Error 2 > > The full build log is available from: > > http://people.debian.org/~lucas/logs/2012/03/30/suricata_1.2.1-1_unstable.log > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > About the archive rebuild: The rebuild was done on about 50 AMD64 nodes > of the Grid'5000 platform, using a clean chroot. Internet was not > accessible from the build systems. > > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#662944: [security] embedded copy of phpCAS
Salut, J'ai essayé d'envoyer le mail qui suit, mais il a été refusé par le serveur de ML (je ne suis pas inscrit avec la bonne adresse ..). Je le transmet donc directement, en attendant de m'inscrire. A+, Pierre Hi, Two security issues have been reported in phpCAS, which is embedded in glpi: http://seclists.org/oss-sec/2012/q1/551 I'm following this information so you can check if the embedded copy needs an update, since you are also distributing it in the standard tarball. Note that in the Debian package I intend to remove it from the package, since code copies are not something good, both for maintenance and security. The best solution would be to create a separate package for phpcas and maintain it, if someone volunteers that would be nice :) Regards, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#662944: [security] embedded copy of phpCAS
Hi, Two security issues have been reported in phpCAS, which is embedded in glpi: http://seclists.org/oss-sec/2012/q1/551 I'm following this information so you can check if the embedded copy needs an update, since you are also distributing it in the standard tarball. Note that in the Debian package I intend to remove it from the package, since code copies are not something good, both for maintenance and security. The best solution would be to create a separate package for phpcas and maintain it, if someone volunteers that would be nice :) Regards, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#659383: CVE-2011-1037
On Fri, Feb 10, 2012 at 05:51:28PM +0100, Moritz Muehlenhoff wrote: > Package: glpi > Severity: important > Tags: security > > Please see > http://permalink.gmane.org/gmane.comp.security.full-disclosure/84497 > Hi, I've prepared the package for unstable and will upload it just after sending this email. According to the advisory, stable version (0.72.4) is not affected. Cheers, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#652756: sslsniff: FTBFS: SSLConnectionManager.cpp:47:74: error: 'boost::asio::ip::tcp::acceptor' has no member named 'io_service'
retitle 652756 sslsniff: does not build with boost 1.48 severity 652756 normal thanks Hi, This was caused by the temporary upload of boost-dev defaulting to 1.48, which was reverted to 1.46 (so not affecting the current version anymore). I'm keeping the bug open to track the compatibility with boost 1.48. Pierre On Tue, Dec 20, 2011 at 03:50:49PM +0100, Lucas Nussbaum wrote: > Source: sslsniff > Version: 0.8-2 > Severity: serious > Tags: wheezy sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20111220 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part: > > g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" > > -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" > > -DPACKAGE=\"sslsniff\" -DVERSION=\"0.8\" -DSTDC_HEADERS=1 > > -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 > > -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 > > -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I.-ggdb -g -O2 -MT > > SSLConnectionManager.o -MD -MP -MF .deps/SSLConnectionManager.Tpo -c -o > > SSLConnectionManager.o SSLConnectionManager.cpp > > In file included from SSLBridge.hpp:41:0, > > from HTTPSBridge.hpp:24, > > from FirefoxUpdater.hpp:23, > > from FirefoxAddonUpdater.hpp:26, > > from SSLConnectionManager.cpp:20: > > certificate/Certificate.hpp: In member function 'std::string > > Certificate::parseNameFromOCSPUrl(std::string&)': > > certificate/Certificate.hpp:60:52: warning: overflow in implicit constant > > conversion [-Woverflow] > > SSLConnectionManager.cpp: In member function 'void > > SSLConnectionManager::acceptIncomingConnection()': > > SSLConnectionManager.cpp:47:74: error: 'boost::asio::ip::tcp::acceptor' has > > no member named 'io_service' > > SSLConnectionManager.cpp: In member function 'void > > SSLConnectionManager::shuttleConnection(boost::shared_ptr > > >, boost::asio::ip::tcp::endpoint&)': > > SSLConnectionManager.cpp:79:78: error: 'boost::asio::ip::tcp::acceptor' has > > no member named 'io_service' > > SSLConnectionManager.cpp: In member function 'void > > SSLConnectionManager::interceptSSL(boost::shared_ptr > > >, boost::asio::ip::tcp::endpoint&, bool)': > > SSLConnectionManager.cpp:137:41: error: 'boost::asio::ip::tcp::acceptor' > > has no member named 'io_service' > > make[1]: *** [SSLConnectionManager.o] Error 1 > > The full build log is available from: > > http://people.debian.org/~lucas/logs/2011/12/20/sslsniff_0.8-2_lsid64.buildlog > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > About the archive rebuild: The rebuild was done on about 50 AMD64 nodes > of the Grid'5000 platform, using a clean chroot. Internet was not > accessible from the build systems. > > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#649599: ITP: tpm-tools -- Management tools for the TPM hardware
Package: wnpp Severity: wishlist Owner: Pierre Chifflier * Package name: tpm-tools Version : 1.3.7 Upstream Author : Kent Yoder * URL : http://trousers.sourceforge.net/ * License : CPL (http://www.opensource.org/licenses/cpl1.0.php) Programming Lang: C Description : Management tools for the TPM hardware tpm-tools is a group of tools to manage and utilize the Trusted Computing Group's TPM hardware. TPM hardware can create, store and use RSA keys securely (without ever being exposed in memory), verify a platform's software state using cryptographic hashes and more. . This package contains tools to allow the platform administrator the ability to manage and diagnose the platform's TPM. Additionally, the package contains commands to utilize some of the capabilities available in the TPM PKCS#11 interface implemented in the openCryptoki project. Note that this is not really a new package: it was part of main, but was orphaned, and removed due to the lack of maintainer and low popcon [1]. Since I'm now using this tool, and that it is required to make a TPM work, I'm adopting it. Pierre [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543927 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#632090:
On Sat, Nov 19, 2011 at 10:18:15PM +0100, Leo Iannacone wrote: > Some news? :) > Hi, This bug had somehow disappeared in my mailbox. This is now fixed in 0.8-2. Cheers, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#638061: xtables-addons: next release
On Mon, Nov 21, 2011 at 04:29:10PM +1100, Dmitry Smirnov wrote: > Recently I did some work on the package which I believe solve this problem. > > However it have been 12 days since I wrote to maintainer but got no > reply so far. > > To get this work some visibility I put my changes to > > > http://anonscm.debian.org/gitweb/?p=users/onlyjob-guest/xtables-addons.git > > and also prepared a source package for review: > > > http://mentors.debian.net/debian/pool/main/x/xtables-addons/xtables-addons_1.39-1.dsc > > Unless Pierre will respond in the following weeks it might become a base > for NMU. > Hi Dmitry, I have seen your email, but the changes from the current packaging are important so please give me a few days to review them. I'm also ok with a co-maintenance, this will eventually be done with the next upload. In the meantime, please do not NMU. Cheers, Pierre signature.asc Description: Digital signature
Bug#648675: ocsinventory-server: ocsinventory can't be contacted from fusioninventory-agent
close 648675 thanks On Mon, Nov 14, 2011 at 12:18:19AM +0100, J.Pietschmann wrote: > Package: ocsinventory-server > Version: 2.0.2-2 > Severity: important > Tags: upstream > > Dear Maintainer, > > the ocsinventory server wont work with fusioninventory-agent since the upgrade > to 2.0 in wheezy, this includes the > fusioninventory-agent 2.1.10-1 in wheezy. The agent gets a 400 "Bad Request" > when accessing > http://localhost/ocsinventory, ocsinventory logs > 127.0.0.1;FusionInventory-Agent_v2.1.10;useragent;Bad agent or agent version > too recent for server !! > Hi, This has been discussed with OCSInventory upstream some time ago, and the solution is described in the README.Debian file: / Support for other agents Starting from version 2.0.2, support for non-native agents has been included upstream. To add support for another agent, edit file etc/ocsinventory/ocsinventory-server.conf and add:: PerlSetEnv OCS_OPT_EXT_USERAGENTS_FILE_PATH /etc/ocsinventory/agents.txt Create file /etc/ocsinventory/agents.txt and add one agent name per line. / > > The reason is probably an regression in the upstream code when checking the > agent for validity in > /usr/share/perl5/Apache/Ocsinventory/Server/Useragent.pm, sub > useragent_prolog_read > A proper fix is probably to extend %ocsagents with an entry for > FusionInventory-Agent. > Nope, the solution chosen by upstream is the user-agents file. > I worked around the problem by using a hook in > /etc/oscinventory/ocsinventory.conf: > PerlSetEnv OCS_OPT_EXT_USERAGENTS_FILE_PATH > "/etc/ocsinventory/ext-useragents" > and put FusionInventory-Agent_v2.1.10 in there > That is documented in the README.Debian file. Regards, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#502305: ulogd2: Status of package?
On Thu, Nov 03, 2011 at 04:36:31PM +0100, Nils Olav Fossum wrote: > Hi, > > I just wonder if there is any news on getting the ulogd2 package into debian. Hi, Thanks for raising this bug report .. I had tons of stuff to do, and left the ulogd packages for too long. I have started again some work here. > > Could it be uploaded to experimental as a first? > That way it should get some testing.. Indeed. The libnetfilter-log problem is now resolved (version in unstable is ok). The main problem remains the upgrade path (if any) from ulogd. > > I need ulog2 on a handful of machines now, so I started with the files at > https://www.wzdftpd.net/downloads/ulogd2-deb/ > > I used instructions from Jim Barber > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502305#73 > (thanks, that saved me a lot of research time!) > to build the package on a amd64 wheezy machine. > > The build failed at the end creating ulogd-output-pcap_2.0.0~beta4-1_amd64.deb > It could not find usr/lib/ulogd/ulogd_output_PCAP.so* This is caused by the multiarch changes in libpcap-dev. > > I applied some of the patches from upstream, but that did not help. > > In the end I cheated, and just commented out the line > usr/lib/ulogd/ulogd_output_PCAP.so* > in debian/ulogd-output-pcap.install. > Not a real fix of course.. I have solved this issue here. Part of the fix is to use: override_dh_auto_configure: ,,,dh_auto_configure -- --with-pcap-lib=/usr/lib/$(DEB_HOST_MULTIARCH) in debian/rules. Regards, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#645612: libopenscap1 and libopenscap0: error when trying to install together
On Mon, Oct 17, 2011 at 02:39:52PM +0200, Julien Cristau wrote: > On Mon, Oct 17, 2011 at 14:13:03 +0200, Pierre Chifflier wrote: > > > On Mon, Oct 17, 2011 at 01:20:53PM +0200, Ralf Treinen wrote: > > > Package: libopenscap0,libopenscap1 > > > Version: libopenscap0/0.7.3-1 > > > Version: libopenscap1/0.8.0-1 > > > Severity: serious > > > User: trei...@debian.org > > > Usertags: edos-file-overwrite > > > > > > Date: 2011-10-17 > > > Architecture: amd64 > > > Distribution: sid > > > > > > Hi, > > > > > > automatic installation tests of packages that share a file and at the > > > same time do not conflict by their package dependency relationships has > > > detected the following problem: > > > > Arg, I forgot to add the Conflict/Replace lines for the transition. > > I'll upload a fixed version ASAP. In the meantime you can safely remove > > libopenscap0 (both versions are not meant to be installed at the same > > time). > > > Note that that'd still be buggy. Shared library packages must not > contain non-versioned files, see policy 8.2. Please fix this properly > instead. > Yep, according to policy 8.2 the probe files (required by the lib at runtime, and cannot be run by user directly) should go to /usr/lib/openscap1 instead of /usr/lib/openscap/ and the only binary to another package. I'll take care of that after this upload. Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#645612: libopenscap1 and libopenscap0: error when trying to install together
On Mon, Oct 17, 2011 at 01:20:53PM +0200, Ralf Treinen wrote: > Package: libopenscap0,libopenscap1 > Version: libopenscap0/0.7.3-1 > Version: libopenscap1/0.8.0-1 > Severity: serious > User: trei...@debian.org > Usertags: edos-file-overwrite > > Date: 2011-10-17 > Architecture: amd64 > Distribution: sid > > Hi, > > automatic installation tests of packages that share a file and at the > same time do not conflict by their package dependency relationships has > detected the following problem: Arg, I forgot to add the Conflict/Replace lines for the transition. I'll upload a fixed version ASAP. In the meantime you can safely remove libopenscap0 (both versions are not meant to be installed at the same time). BR, Pierre > > > WARNING: The following packages cannot be authenticated! > libsasl2-2 libldap-2.4-2 libpcre3 libnl1 libcap2 libxml2 libxslt1.1 > libopenscap0 libopenscap1 > Authentication warning overridden. > Can not write log, openpty() failed (/dev/pts not mounted?) > Selecting previously unselected package libsasl2-2. > (Reading database ... 10586 files and directories currently installed.) > Unpacking libsasl2-2 (from .../libsasl2-2_2.1.25.dfsg1-2_amd64.deb) ... > Selecting previously unselected package libldap-2.4-2. > Unpacking libldap-2.4-2 (from .../libldap-2.4-2_2.4.25-3_amd64.deb) ... > Selecting previously unselected package libpcre3. > Unpacking libpcre3 (from .../libpcre3_8.12-4_amd64.deb) ... > Selecting previously unselected package libnl1. > Unpacking libnl1 (from .../libnl1_1.1-7_amd64.deb) ... > Selecting previously unselected package libcap2. > Unpacking libcap2 (from .../libcap2_1%3a2.22-1_amd64.deb) ... > Selecting previously unselected package libxml2. > Unpacking libxml2 (from .../libxml2_2.7.8.dfsg-5_amd64.deb) ... > Selecting previously unselected package libxslt1.1. > Unpacking libxslt1.1 (from .../libxslt1.1_1.1.26-8_amd64.deb) ... > Selecting previously unselected package libopenscap0. > Unpacking libopenscap0 (from .../libopenscap0_0.7.3-1_amd64.deb) ... > Selecting previously unselected package libopenscap1. > Unpacking libopenscap1 (from .../libopenscap1_0.8.0-1_amd64.deb) ... > dpkg: error processing /var/cache/apt/archives/libopenscap1_0.8.0-1_amd64.deb > (--unpack): > trying to overwrite '/usr/bin/oscap', which is also in package libopenscap0 > 0.7.3-1 > configured to not write apport reports > dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) > Processing triggers for man-db ... > Errors were encountered while processing: > /var/cache/apt/archives/libopenscap1_0.8.0-1_amd64.deb > E: Sub-process /usr/bin/dpkg returned an error code (1) > > > This is a serious bug as it makes installation fail, and violates > sections 7.6.1 and 10.1 of the policy. An optimal solution would > consist in only one of the packages installing that file, and renaming > or removing the file in the other package. Depending on the > circumstances you might also consider Replace relations or file > diversions. If the conflicting situation cannot be resolved then, as a > last resort, the two packages have to declare a mutual > Conflict. Please take into account that Replaces, Conflicts and > diversions should only be used when packages provide different > implementations for the same functionality. > > Here is a list of files that are known to be shared by both packages > (according to the Contents file for sid/amd64, which may be > slightly out of sync): > > /usr/bin/oscap > /usr/lib/openscap/probe_dnscache > /usr/lib/openscap/probe_dpkginfo > /usr/lib/openscap/probe_family > /usr/lib/openscap/probe_file > /usr/lib/openscap/probe_filehash > /usr/lib/openscap/probe_inetlisteningservers > /usr/lib/openscap/probe_interface > /usr/lib/openscap/probe_ldap57 > /usr/lib/openscap/probe_partition > /usr/lib/openscap/probe_password > /usr/lib/openscap/probe_process > /usr/lib/openscap/probe_runlevel > /usr/lib/openscap/probe_shadow > /usr/lib/openscap/probe_sysctl > /usr/lib/openscap/probe_system_info > /usr/lib/openscap/probe_textfilecontent > /usr/lib/openscap/probe_textfilecontent54 > /usr/lib/openscap/probe_uname > /usr/lib/openscap/probe_xinetd > /usr/lib/openscap/probe_xmlfilecontent > /usr/share/man/man8/oscap.8.gz > /usr/share/openscap/scap-fedora14-oval.xml > /usr/share/openscap/scap-fedora14-xccdf.xml > /usr/share/openscap/scap-rhel6-oval.xml > /usr/share/openscap/scap-rhel6-xccdf.xml > /usr/share/openscap/schemas/oval/5.8/aix-definitions-schema.xsd > /usr/share/openscap/schemas/oval/5.8/aix-system-characteristics-schema.xsd > /usr/share/openscap/schemas/oval/5.8/apache-definitions-schema.xsd > > /usr/share/openscap/schemas/oval/5.8/apache-system-characteristics-schema.xsd > /usr/share/openscap/schemas/oval/5.8/catos-definitions-schema.xsd > /usr/share/openscap/schemas/oval/5.8/catos-system-characteristics-schema.xsd > /usr/share/openscap/schemas/oval/5.8/debian-definitions-schema.xsd > > /usr
Bug#644928: ITP: dff -- A powerful, efficient and modular digital forensic tool
Package: wnpp Severity: wishlist Owner: Pierre Chifflier * Package name: dff Version : 1.2.0 Upstream Author : ArxSys * URL : http://www.digital-forensic.org/ * License : GPLv2 Programming Lang: C and Python Description : A powerful, efficient and modular digital forensic tool This is the description from the website: The Digital Forensics Framework (DFF) is both a digital investigation tool and a development platform. The framework is used by system administrators, law enforcement examinors, digital forensics researchers and students, and security professionals world-wide. Written in Python and C++, it exclusively uses Open Source technologies. DFF combines an intuitive user interface with a modular and cross-platform architecture. DFF consists of tools, libraries, modules, and user interfaces. The basic function of the framework is to agregate information and methodologicaly analyze volumes, file systems, user and applications data, while extracting metadata, deleted and hidden items. Information are processed into virtual read-only containers, thus preserving the integrity and authenticity of data. BR, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#644427: [Pkg-openldap-devel] Bug#644427: openldap: please enable hardening options
On Wed, Oct 05, 2011 at 01:26:47PM -0700, Steve Langasek wrote: > tags 644427 - patch > thanks > > On Wed, Oct 05, 2011 at 09:10:57PM +0200, Pierre Chifflier wrote: > > > --- openldap-2.4.25.orig/debian/rules 2011-10-05 18:56:46.0 > > +0200 > > +++ openldap-2.4.25/debian/rules2011-10-05 18:09:23.0 +0200 > > @@ -6,7 +6,10 @@ > > # want the checks for DFSG-freeness. > > #DFSG_NONFREE = 1 > > > > -CFLAGS = -Wall -g -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE > > +DPKG_EXPORT_BUILDFLAGS = 1 > > +include /usr/share/dpkg/buildflags.mk > > + > > +CFLAGS += -Wall -g -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE > > INSTALL = install > > INSTALL_FILE= $(INSTALL) -p-o root -g root -m 644 > > INSTALL_PROGRAM = $(INSTALL) -p-o root -g root -m 755 > > nack on this implementation. makefile includes are a terrible interface. Sure. As written, the rationale was to propose a patch with minimal changes. > > I am intending to spend some time this weekend to work on bringing the > openldap packaging up to dh(1) and compat level 9 so we can let debhelper > take care of this for us (like it ought). The most problematic change I can see is that dh 9 also includes multi-arch, and since openldap use a lot of shared libraries this could be tricky. Thanks for taking care of that ! Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#644437: amanda: please enable hardening options
Source: amanda Severity: normal Tags: patch User: debian...@lists.debian.org Usertags: hardening Hardening options is a proposed release goal for Wheezy [1]. Having important package, interpreters and daemons compiled with the hardening options will add various protections against issues such as stack smashing, predictable locations of values in memory, etc. I have rebuilt the package with hardening options enabled and there was no error (during build, or at runtime). The attached patch adds a minimal modification to the debian/rules file to add support for hardening flags (other methods are available). Note that PIE and bindnow are not enabled by default, and that you can decide to enable this options for additional features (see the following link for details). You can control and enable/disable each hardening flag independently, see http://lists.debian.org/debian-devel-announce/2011/09/msg1.html for details. Thanks, Pierre [1] http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags diff -ruN amanda-3.3.0.orig/debian/rules amanda-3.3.0/debian/rules --- amanda-3.3.0.orig/debian/rules 2011-09-13 23:13:04.0 +0200 +++ amanda-3.3.0/debian/rules 2011-10-05 21:45:44.225039861 +0200 @@ -3,6 +3,9 @@ export DH_VERBOSE=1 +DPKG_EXPORT_BUILDFLAGS = 1 +-include /usr/share/dpkg/buildflags.mk + r=$(shell pwd)/debian/amanda-common s=$(shell pwd)/debian/amanda-server c=$(shell pwd)/debian/amanda-client @@ -51,7 +54,7 @@ build-indep: build-stamp build-stamp: configure-stamp dh_testdir - MAILER=/usr/bin/mail $(MAKE) CFLAGS="-O2 -g -Wall \ + MAILER=/usr/bin/mail $(MAKE) CFLAGS="$(CFLAGS) -O2 -g -Wall \ -DAMANDATES_FILE='\"/var/lib/amanda/amandates\"' \ -DIGNORE_TAR_ERRORS " touch build-stamp
Bug#644427: openldap: please enable hardening options
Source: openldap Severity: normal Tags: patch User: debian...@lists.debian.org Usertags: hardening Hardening options is a proposed release goal for Wheezy [1]. Having important package, interpreters and daemons compiled with the hardening options will add various protections against issues such as stack smashing, predictable locations of values in memory, etc. I have rebuilt the package with hardening options enabled and there was no error (during build, or at runtime). The attached patch adds a minimal modification to the debian/rules file to add support for hardening flags (other methods are available). Note that PIE and bindnow are not enabled by default, and that you can decide to enable this options for additional features (see the following link for details). You can control and enable/disable each hardening flag independently, see http://lists.debian.org/debian-devel-announce/2011/09/msg1.html for details. Thanks, Pierre [1] http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags --- openldap-2.4.25.orig/debian/rules 2011-10-05 18:56:46.0 +0200 +++ openldap-2.4.25/debian/rules2011-10-05 18:09:23.0 +0200 @@ -6,7 +6,10 @@ # want the checks for DFSG-freeness. #DFSG_NONFREE = 1 -CFLAGS = -Wall -g -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE +DPKG_EXPORT_BUILDFLAGS = 1 +include /usr/share/dpkg/buildflags.mk + +CFLAGS += -Wall -g -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE INSTALL = install INSTALL_FILE= $(INSTALL) -p-o root -g root -m 644 INSTALL_PROGRAM = $(INSTALL) -p-o root -g root -m 755
Bug#644413: isc-dhcp: please enable hardening options
Source: isc-dhcp Severity: normal Tags: patch User: debian...@lists.debian.org Usertags: hardening Hardening options is a proposed release goal for Wheezy [1]. Having important package, interpreters and daemons compiled with the hardening options will add various protections against issues such as stack smashing, predictable locations of values in memory, etc. I have rebuilt the package with hardening options enabled and there was no error (during build, or at runtime). The attached patch adds a minimal modification to the debian/rules file to add support for hardening flags (other methods are available). Note that PIE and bindnow are not enabled by default, and that you can decide to enable this options for additional features (see the following link for details). You can control and enable/disable each hardening flag independently, see http://lists.debian.org/debian-devel-announce/2011/09/msg1.html for details. Thanks, Pierre [1] http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags --- isc-dhcp-4.2.2.orig/debian/rules2011-10-05 17:32:37.0 +0200 +++ isc-dhcp-4.2.2/debian/rules 2011-10-05 17:07:18.0 +0200 @@ -22,7 +22,10 @@ include /usr/share/dpatch/dpatch.make -CFLAGS = -Wall -g +DPKG_EXPORT_BUILDFLAGS = 1 +-include /usr/share/dpkg/buildflags.mk + +CFLAGS += -Wall -g INSTALL = install INSTALL_FILE = $(INSTALL) -p -o root -g root -m 644
Bug#644412: dpkg-buildflags: use DEB_BUILD_MAINT_OPTIONS when including buildflags.mk
Package: dpkg Version: 1.16.1 Severity: normal Hi, When using the following Makefile snippet: DEB_BUILD_MAINT_OPTIONS = hardening=+pie,+bindnow export DEB_BUILD_MAINT_OPTIONS -include /usr/share/dpkg/buildflags.mk export CFLAGS LDFLAGS The variable DEB_BUILD_MAINT_OPTIONS is not used, and the variables (CFLAGS etc.) does not have the expected value. A possible solution would be to modify /usr/share/dpkg/buildflags.mk to use the variables when running the shell command, for ex using something like: DEB_BUILD_MAINT_OPTIONS="$(DEB_BUILD_MAINT_OPTIONS)" dpkg-buildflags This would greatly help for the hardening goal by keeping the inclusion of the file optional (for backports) and adding options like pie and bindnow to the hardening flags. Thanks, Pierre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#644408: aiccu: please enable hardening options
Source: aiccu Severity: normal Tags: patch User: debian...@lists.debian.org Usertags: hardening Hardening options is a proposed release goal for Wheezy [1]. Having important package, interpreters and daemons compiled with the hardening options will add various protections against issues such as stack smashing, predictable locations of values in memory, etc. I have rebuilt the package with hardening options enabled and there was no error (during build, or at runtime). The attached patch adds a minimal modification to the debian/rules file to add support for hardening flags (other methods are available). Note that PIE and bindnow are not enabled by default, and that you can decide to enable this options for additional features (see the following link for details). You can control and enable/disable each hardening flag independently, see http://lists.debian.org/debian-devel-announce/2011/09/msg1.html for details. Thanks, Pierre [1] http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags --- aiccu-20070115.orig/debian/rules2011-10-05 16:39:54.0 +0200 +++ aiccu-20070115/debian/rules 2011-10-05 16:44:50.0 +0200 @@ -6,6 +6,11 @@ # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 +DPKG_EXPORT_BUILDFLAGS = 1 +-include /usr/share/dpkg/buildflags.mk +RPM_OPT_FLAGS = $(CFLAGS) +export RPM_OPT_FLAGS + include /usr/share/quilt/quilt.make %:
Bug#644402: tcsh: please enable hardening options
Source: tcsh Severity: normal Tags: patch User: debian...@lists.debian.org Usertags: hardening Hardening options is a proposed release goal for Wheezy [1]. Having important package compiled with the hardening options will add various protections against issues such as stack smashing, predictable locations of values in memory, etc. I have rebuilt the package with hardening options enabled and there was no error (during build, or at runtime). The attached patch adds a minimal modification to the debian/rules file to add support for hardening flags (other methods are available). Note that PIE and bindnow are not enabled by default, and that you can decide to enable this options for additional features (see the following link for details). You can control and enable/disable each hardening flag independently, see http://lists.debian.org/debian-devel-announce/2011/09/msg1.html for details. Thanks, Pierre diff -ruN tcsh-6.17.06.orig/debian/rules tcsh-6.17.06/debian/rules --- tcsh-6.17.06.orig/debian/rules 2011-10-05 16:18:33.0 +0200 +++ tcsh-6.17.06/debian/rules 2011-10-05 16:13:23.0 +0200 @@ -3,6 +3,9 @@ # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 +-include /usr/share/dpkg/buildflags.mk +export CPPFLAGS CFLAGS LDFLAGS + CFLAGS += -D_FILE_OFFSET_BITS=64 %:
Bug#644400: zsh: please enable hardening options
Source: zsh
Severity: normal
Tags: patch
User: debian...@lists.debian.org
Usertags: hardening
Hardening options is a proposed release goal for Wheezy [1].
Having important package compiled with the hardening options will add
various protections against issues such as stack smashing, predictable
locations of values in memory, etc.
I have rebuilt the package with hardening options enabled and there was
no error (during build, or at runtime).
The attached patch adds a minimal modification to the debian/rules file
to add support for hardening flags (other methods are available).
Note that PIE and bindnow are not enabled by default, and that you can
decide to enable this options for additional features (see the following
link for details).
You can control and enable/disable each hardening flag independently,
see
http://lists.debian.org/debian-devel-announce/2011/09/msg1.html
for details.
Thanks,
Pierre
[1] http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags
diff -ruN zsh-4.3.12.orig/debian/rules zsh-4.3.12/debian/rules
--- zsh-4.3.12.orig/debian/rules 2011-06-14 20:14:07.0 +0200
+++ zsh-4.3.12/debian/rules 2011-10-05 16:01:29.0 +0200
@@ -10,12 +10,16 @@
snapshot_date := $(shell dpkg-parsechangelog | sed -n '/^Version: [0-9.][0-9.]*.*+20[0-9][0-9]\([0-9][0-9][0-9][0-9]\)-[0-9][0-9]*$$/ {s//\1/;p}')
endif
-CFLAGS = -Wall -g
+-include /usr/share/dpkg/buildflags.mk
+export CFLAGS LDFLAGS
+H_LDFLAGS = $(LDFLAGS)
+
+CFLAGS += -Wall -g
ifeq (zsh-beta,$(package))
CFLAGS += -W
endif
-CONFIGFLAGS = --prefix=/usr --mandir=/usr/share/man --bindir=/bin LDFLAGS="-Wl,--as-needed -g"
+CONFIGFLAGS = --prefix=/usr --mandir=/usr/share/man --bindir=/bin LDFLAGS="-Wl,--as-needed -g $(H_LDFLAGS)"
ifeq (zsh-beta,$(package))
CONFIGFLAGS += --program-suffix=-beta
Bug#644335: clamav: please enable hardening options
Source: libclamav6 Severity: normal Tags: patch User: debian...@lists.debian.org Usertags: hardening Hardening options is a proposed release goal for Wheezy [1]. clamav is a package with code exposed to malicious software, so having its package compiled with the hardening options seems really like a good idea. I have rebuilt the package with hardening options enabled and there was no error (during build, or at runtime). The only required patch is to update the following in debian/rules: DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/buildflags.mk CFLAGS += -Wall -g CXXFLAGS += -Wall -g and the package will use dpkg-buildflags, which in turn enable the hardening options. Note that PIE and bindnow are not enabled by default. This can be done using: DEB_BUILD_MAINT_OPTIONS = hardening=+pie,+bindnow in the debian/rules file. You can control and enable/disable each hardening flag independently, see http://lists.debian.org/debian-devel-announce/2011/09/msg1.html for details. Thanks, Pierre [1] http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#644303: rsyslog: please enable hardening options
Source: rsyslog Version: 5.8.5-1 Severity: normal Tags: patch User: debian...@lists.debian.org Usertags: hardening Hardening options is a proposed release goal for Wheezy [1]. rsyslog is widely deployed on Debian systems, so having its package compiled with the hardening options seems really like a good idea. I have rebuilt the package with hardening options enabled and there was no error (during build, or at runtime). The only required patch is to add the following to debian/rules: DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/buildflags.mk and the package will use dpkg-buildflags, which in turn enable the hardening options. Note that PIE and bindnow are not enabled by default. This can be done using: DEB_BUILD_MAINT_OPTIONS = hardening=+pie,+bindnow in the debian/rules file. You can control and enable/disable each hardening flag independently, see http://lists.debian.org/debian-devel-announce/2011/09/msg1.html for details. Thanks, Pierre [1] http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
