Bug#955166: FTBFS with gcc-9: undefined reference to bsd_getopt, etc.
Package: src:kfreebsd-10
Version: 10.3~svn300087-5
Severity: serious
Tags: patch
kfreebsd-10 FTBFS with gcc-9 due to:
| gcc-9 -D_GNU_SOURCE -isystem /usr/include/freebsd
-I/home/build/kfreebsd-10-10.3~svn300087/flavor-10.3-0-amd64/sys/modules/aic7xxx/aicasm
-I../../../dev/aic7xxx/aicasm -std=gnu99 -fstack-protector -Wno-pointer-sign
-Wno-missing-prototypes -ldb -lbsd -o aicasm aicasm.o aicasm_symbol.o
aicasm_gram.o aicasm_macro_gram.o aicasm_scan.o aicasm_macro_scan.o -ll
| /usr/bin/ld: aicasm.o: in function `main':
| aicasm.c:(.text+0x4a1): undefined reference to `bsd_getopt'
| /usr/bin/ld: aicasm_symbol.o: in function `symtable_open':
| aicasm_symbol.c:(.text+0x220): undefined reference to `__db185_open'
| collect2: error: ld returned 1 exit status
| *** [aicasm] Error code 1
The linker invocation now adds the "--as-needed" parameter by default,
before -ldb and -lbsd, and furthermore those libraries were linked in
before the object files which use their functions:
| /usr/lib/gcc/x86_64-kfreebsd-gnu/9/collect2 -plugin
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-kfreebsd-gnu/9/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccgJKsnR.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr -m elf_x86_64_fbsd --hash-style=gnu --as-needed -dynamic-linker
/lib/ld-kfreebsd-x86-64.so.1 -pie -o aicasm
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu/Scrt1.o
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu/crti.o
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/crtbeginS.o
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../../lib -L/lib/x86_64-kfreebsd-gnu
-L/lib/../lib -L/usr/lib/x86_64-kfreebsd-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../.. -ldb -lbsd a
icasm.o aicasm_symbol.o aicasm_gram.o aicasm_macro_gram.o aicasm_scan.o
aicasm_macro_scan.o -ll -lgcc --push-state --as-needed -lgcc_s --pop-state -lc
-lgcc --push-state --as-needed -lgcc_s --pop-state
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/crtendS.o
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu/crtn.o
As a result, those libraries would not be linked in at all. Object
files aicasm.o, aicasm_symbol.o subsequently cannot find find the
required functions.
I've fixed this by using LDADD within the Makefile, instead of
LDFLAGS within our debian/rules, to add the library dependencies.
Now the library dependencies are added after the object files,
as they should be.
-- System Information:
Debian Release: 8.0
APT prefers stable-kfreebsd-proposed-updates
APT policy: (500, 'stable-kfreebsd-proposed-updates'), (500,
'stable-kfreebsd')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Date: Fri, 27 Mar 2020 21:26:21 +
From: Steven Chamberlain
Subject: Add extra libs required to build aicasm
--- a/sys/dev/aic7xxx/aicasm/Makefile
+++ b/sys/dev/aic7xxx/aicasm/Makefile
@@ -14,7 +14,7 @@ GENHDRS= aicasm_gram.h aicasm_macro_gram
SRCS= ${GENHDRS} ${CSRCS} ${YSRCS} ${LSRCS}
CLEANFILES+= ${GENHDRS} ${YSRCS:R:C/(.*)/\1.output/g}
DPADD= ${LIBL}
-LDADD= -ll
+LDADD= -ldb -lbsd -ll
WARNS?=0
# Correct path for kernel builds
Bug#868929: kfreebsd-10: FTBFS: ../../../compat/ia32/ia32_genassym.c:1:0: error: code model kernel does not support PIC mode
severity 868929 important thanks (linux-)amd64 is not in this package's Architectures: field, therefore FTBFS on that arch cannot be a RC bug? (Though I'd be interested in fixing it someday). Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#858377: libblkmaker: doesn't support current bitcoin block version
Package: libblkmaker Version: 0.5.3-1 Severity: grave Tags: fixed-upstream Hi, The version of libblkmaker in sid/stretch supports bitcoin blocks up to version 4 only: http://sources.debian.net/src/libblkmaker/0.5.3-1/blkmaker.h/#L15 But since early 2016, the tip of the blockchain uses predemonantly versions 0x2000 or later: https://data.bitcoinity.org/bitcoin/block_version/5y?c=block_version&t=a That seems to make bfgminer unusable; it looks at the tip of the bitcoin blockchain and throws the error, failing to start: "Unrecognized block version, and not allowed to reduce or force it" The current Git master of libblkmaker added support for this: https://github.com/bitcoin/libblkmaker/commit/ae7055df8bbb72dd42dcb6a8d1440ca87da6b0f3 https://github.com/bitcoin/libblkmaker/commit/0d8212c1dcf9dab28d749c08bd107ce0f06d45e3 but I found that bfgminer would still not work unless it also sets BMM_VERFORCE in tmpl->mutations I'm not entirely familiar with any of the above-mentioned software but hopefully the upstream author luke-kr (in Cc:) could comment on these issues. Many thanks! -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 10.1-0-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
Control: tags -1 - patch I've no more desire to work on this bug, sorry. Thanks for the feedback that was given, but it has already been more effort than I have time or patience to contribute. For what should be essentially, s/md5/sha256/ in a few places, the required procedures and personal interactions beyond that, is just too much. That is the real "debacle"; it is not surprising to me now, that this did not happen yet in 10 years, or that no enthusiastic new contributor had already done this. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
Bastian Blank wrote: > On Tue, Feb 28, 2017 at 10:00:01PM +0000, Steven Chamberlain wrote: > > That differs from the latest version of my patch, and from what I sent > > earlier today to the release team when asking about a potential unblock: > > https://lists.debian.org/debian-release/2017/02/msg01033.html > > This happens if you send incomplete patches and do uncoordinated unblock > requests. Maybe you just volunteered to do that, then. You even said before you "don't have time" to write the cdebootstrap patch, so I offered one, and the anna patch, the libdebian-installer patch, all this after the initial discovery, triage and write-up. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
Bastian Blank wrote: > Adopted and commited to > https://anonscm.debian.org/git/d-i/libdebian-installer.git, branch > sha256 That differs from the latest version of my patch, and from what I sent earlier today to the release team when asking about a potential unblock: https://lists.debian.org/debian-release/2017/02/msg01033.html I think we should wait for them to answer before doing anything else. Based on KiBi's feedback I thought it better to swap sum[0] and sum[1], and remove the SHA1 parsing also. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856212: cdebootstrap: please implement SHA256 verification of .deb files
Control: tags -1 + patch
Hi,
The attached patch is based on having
libdebian-installer_bug856210_v3.patch applied:
* libdebian-installer4-dev would not change its name
* sum[1] is already empty/unusable
* sum[0] would become the sha256 field
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
diff --git a/debian/changelog b/debian/changelog
index c73f96e..96b0eee 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+cdebootstrap (0.7.7) UNRELEASED; urgency=medium
+
+ * Team upload.
+ * Implement SHA256 verification of .deb files (Closes: #856212).
+ * Implement SHA256 verification of Packages files.
+- (Build-)Depend on libdebian-installer4-dev >= 0.109 which provides
+ those sha256 fields
+ * Remove support for SHA1 hashes, since they are no longer published
+in Release files, and the full length of them was not previously
+being checked against the expected values (Closes: #856213).
+ * Disallow fallback to MD5-only verification (Closes: #856215).
+
+ -- Steven Chamberlain Mon, 27 Feb 2017 15:53:40 +
+
cdebootstrap (0.7.6) unstable; urgency=medium
* Make generation of tar reproducible. (closes: #37)
diff --git a/debian/control b/debian/control
index 49bb110..6996ce5 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends:
libbz2-dev,
libcurl4-gnutls-dev,
libdebconfclient0-dev (>= 0.40),
- libdebian-installer4-dev (>= 0.81~),
+ libdebian-installer4-dev (>= 0.109~),
liblzma-dev,
pkg-config,
zlib1g-dev
diff --git a/src/check.c b/src/check.c
index 34e96da..c41d9e4 100644
--- a/src/check.c
+++ b/src/check.c
@@ -32,6 +32,9 @@
#include "frontend.h"
#include "suite.h"
+/* Length of a SHA256 hash in hex representation */
+#define SHA256_HEX_LENGTH 64
+
static int check_sum (const char *target, const char *exec, const char *sum, const char *message)
{
int ret;
@@ -51,14 +54,14 @@ static int check_sum (const char *target, const char *exec, const char *sum, con
if (ret)
return 1;
- if (!strncmp (buf, sum, 32))
+ if (!strncmp (buf, sum, SHA256_HEX_LENGTH))
return 0;
return 1;
}
int check_deb (const char *target, di_package *p, const char *message)
{
- return check_sum (target, "md5sum", p->md5sum, message);
+ return check_sum (target, "sha256sum", p->sha256, message);
}
int check_packages (const char *target, const char *ext, di_release *rel)
@@ -72,14 +75,12 @@ int check_packages (const char *target, const char *ext, di_release *rel)
snprintf (buf_file, sizeof (buf_file), "main/binary-%s/Packages%s", arch, ext);
key.string = (char *) buf_file;
key.size = strlen (buf_file);
- item = di_hash_table_lookup (rel->md5sum, &key);
+ item = di_hash_table_lookup (rel->sha256, &key);
if (!item)
log_text (DI_LOG_LEVEL_ERROR, "Can't find checksum for Packages file");
- if (item->sum[1])
-return check_sum (target, "sha1sum", item->sum[1], buf_name);
if (item->sum[0])
-return check_sum (target, "md5sum", item->sum[0], buf_name);
+return check_sum (target, "sha256sum", item->sum[0], buf_name);
return 1;
}
signature.asc
Description: Digital signature
Bug#856211: anna: please implement SHA256 verification of .udeb files
Updated patch, which assumes the libdebian-installer4-dev package will
not be renamed. Build-Depend on a recent enough version that provides
sha256 fields.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
diff --git a/debian/changelog b/debian/changelog
index d6682ca..20e33a0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+anna (1.58) UNRELEASED; urgency=medium
+
+ * Team upload.
+ * Replace md5sum verification with sha256sum (Closes: #856211).
+- (Build-)Depend on libdebian-installer4-dev >= 0.109 which provides
+ those sha256 fields.
+
+ -- Steven Chamberlain Mon, 27 Feb 2017 15:13:37 +
+
anna (1.57) unstable; urgency=medium
[ Updated translations ]
diff --git a/debian/control b/debian/control
index def2af9..4998489 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: debian-installer
Priority: standard
Maintainer: Debian Install System Team
Uploaders: Bastian Blank , Christian Perrier
-Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.15.7), libdebconfclient0-dev (>= 0.46), libdebian-installer4-dev (>= 0.41)
+Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.15.7), libdebconfclient0-dev (>= 0.46), libdebian-installer4-dev (>= 0.109)
Vcs-Browser: https://anonscm.debian.org/cgit/d-i/anna.git
Vcs-Git: https://anonscm.debian.org/git/d-i/anna.git
diff --git a/anna.c b/anna.c
index 4b68816..e03d34a 100644
--- a/anna.c
+++ b/anna.c
@@ -318,8 +318,8 @@ install_modules(di_packages *status, di_packages *packages) {
}
}
-if (! md5sum(package->md5sum, dest_file)) {
- di_log(DI_LOG_LEVEL_WARNING, "bad md5sum");
+if (! sha256sum(package->sha256, dest_file)) {
+ di_log(DI_LOG_LEVEL_WARNING, "bad sha256sum");
if (!quiet)
/* error handling may use a progress bar, so stop the current one */
debconf_progress_stop(debconf);
diff --git a/util.c b/util.c
index 39af3db..7d09cf8 100644
--- a/util.c
+++ b/util.c
@@ -224,23 +224,26 @@ int load_templates (di_packages *packages) {
}
#endif /* LOADTEMPLATES */
-/* Check whether the md5sum of file matches sum. If not, return 0. */
-int md5sum(const char *sum, const char *file) {
+/* Length of a SHA256 hash in hex representation */
+#define SHA256_HEX_LENGTH 64
+
+/* Check whether the sha256sum of file matches sum. If not, return 0. */
+int sha256sum(const char *sum, const char *file) {
FILE *fp;
char line[1024];
- /* Trivially true if the Packages file doesn't have md5sum lines */
+ /* Trivially true if the Packages file doesn't have sha256sum lines */
if (sum == NULL)
return 1;
- snprintf(line, sizeof(line), "/usr/bin/md5sum %s", file);
+ snprintf(line, sizeof(line), "/usr/bin/sha256sum %s", file);
fp = popen(line, "r");
if (fp == NULL)
return 0;
if (fgets(line, sizeof(line), fp) != NULL) {
pclose(fp);
- if (strlen(line) < 32)
+ if (strlen(line) < SHA256_HEX_LENGTH)
return 0;
- line[32] = '\0';
+ line[SHA256_HEX_LENGTH] = '\0';
return !strcmp(line, sum);
}
pclose(fp);
diff --git a/util.h b/util.h
index 71135e0..0c9e0a2 100644
--- a/util.h
+++ b/util.h
@@ -10,7 +10,7 @@ bool is_installed(di_package *p, di_packages *status);
size_t package_to_choice(di_package *package, char *buf, size_t size);
char *list_to_choices(di_package **packages, int c_values);
int get_package (di_package *package, char *dest);
-int md5sum(const char* sum, const char *file);
+int sha256sum(const char* sum, const char *file);
int skip_package(di_package *p);
int package_name_compare(const void *v1, const void *v2);
void take_includes(di_packages *packages);
signature.asc
Description: Digital signature
Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
Steven Chamberlain wrote: > replace sum[0] with sha256 and leave sum[1] empty; > [...] (we would drop the MD5- and SHA1-parsing code > and make absolutely sure nobody is still using those). The new patch attached would do that, and it remains otherwise ABI-compatible. It aims to be the most minimal diff, so it does not extend the testsuite for example, which still passes even though the Packages file testcase has no SHA256 fields. In src/release.c: file->sum[1] is initialised to NULL by a calloc(). In the future, someone might want to put SHA512 hashes there. It does not hurt to keep the existing di_free(file->sum[1]) in place. Within the installer, this should only break anna, until the patch from #856211 is applied. Outside of the installer, cdebootstrap would break, until #856212 is patched. If we missed any other reverse-depends, they should FTBFS if they dereference the md5sum fields. Already-built binaries should report a "md5sum mismatch", if they use the patched libdebian-installer at run-time and still try to do verification with MD5. Regards, -- Steven Chamberlain ste...@pyro.eu.org diff --git a/debian/changelog b/debian/changelog index 3dd29e1..748a78b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,7 +1,17 @@ libdebian-installer (0.109) UNRELEASED; urgency=medium + [ Samuel Thibault ] * Fix build with gcc-7. Closes: #853489 + [ Steven Chamberlain ] + * In structs di_release and di_package, replace md5sum member with a +sha256 member. This is ABI-compatible, but reverse-dependencies +will fail if they still try to verify with MD5 (Closes: #856212). + * Parse SHA256 fields instead of MD5Sum fields in Packages files. + * Parse SHA256 fields instead of MD5Sum fields in Release files. + * No longer try to parse SHA1 field, which is no longer present in +Release files as of stretch. + -- Samuel Thibault Tue, 31 Jan 2017 11:09:16 +0100 libdebian-installer (0.108) unstable; urgency=medium diff --git a/include/debian-installer/package.h b/include/debian-installer/package.h index 72d7444..e1f699d 100644 --- a/include/debian-installer/package.h +++ b/include/debian-installer/package.h @@ -112,7 +112,7 @@ struct di_package di_slist depends; /**< Any different dependency types */ char *filename; /**< Filename field */ size_t size; /**< Size field */ - char *md5sum; /**< MD5Sum field */ + char *sha256; /**< SHA256 field */ char *short_description; /**< Description field, first part*/ char *description;/**< Description field, second part */ unsigned int resolver;/**< @internal */ diff --git a/include/debian-installer/package_internal.h b/include/debian-installer/package_internal.h index f6357d1..d410ce2 100644 --- a/include/debian-installer/package_internal.h +++ b/include/debian-installer/package_internal.h @@ -52,7 +52,7 @@ const di_parser_fieldinfo internal_di_package_parser_field_enhances, internal_di_package_parser_field_filename, internal_di_package_parser_field_size, - internal_di_package_parser_field_md5sum, + internal_di_package_parser_field_sha256, internal_di_package_parser_field_description; /** diff --git a/include/debian-installer/release.h b/include/debian-installer/release.h index 223a4f8..29b0cfb 100644 --- a/include/debian-installer/release.h +++ b/include/debian-installer/release.h @@ -40,7 +40,7 @@ struct di_release char *origin; /**< Origin field */ char *suite; /**< Suite field */ char *codename; /**< Codename field */ - di_hash_table *md5sum;/**< checksum fields, includes di_release_file */ + di_hash_table *sha256;/**< checksum fields, includes di_release_file */ di_mem_chunk *release_file_mem_chunk; /**< @internal */ }; @@ -55,7 +55,7 @@ struct di_release_file di_rstring key; /**< @internal */ }; unsigned int size;/**< size */ - char *sum[2]; /**< checksums, currently md5 and sha1 */ + char *sum[2]; /**< sum[0] is sha256, sum[1] is empty */ }; di_release *di_release_alloc (void); diff --git a/src/package.c b/src/package.c index 653b5dd..82c7653 100644 --- a/src/package.c +++ b/src/package.c @@ -38,7 +38,7 @@ void di_package_destroy (di_package *package) di_free (package->architecture); di_free (package->version); di_free (package->filename); - di_free (package->md5sum); + di_free (package->sha256);
Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
Thanks for your comments!
Cyril Brulebois wrote:
> Steven Chamberlain (2017-02-27):
> > (If we really wanted, we could maybe avoid the ABI bump: [...]
>
> Given the number of reverse dependencies, I doubt this is worth abusing
> md5 storage for sha256 things.
Maybe I should clarify that; the current libdebian-installer/0.108 has:
di_package struct {
...
char *md5sum; // -> dynamically allocated md5sum field
...
}
and we'd be changing it to:
di_package struct {
...
char *sha256; // -> dynamically allocated sha256 field
...
}
("Sum" was dropped from name of that field in the Release file, so I do
the same here)
Changing the name, causes reverse-deps using that field to FTBFS. I
think that is just anna and cdebootstrap, which we'd patch anyway.
The md5sum/sha256 field is a pointer to a dynamically-allocated field.
The struct size, and the offset of other members does not change, so
nothing else should need rebuilding with the newer package.h
"If" somehow, we missed something, which tries to dereference
package->md5sum at run-time with a new version of libdebian-installer,
it would find a sha256 hash there instead of md5. That should fail
"safely" by complaining of a md5sum mismatch (even if it only compares
the first 32 bytes, as cdebootstrap does currently).
That's why I think an ABI bump could be safely avoided. (And I think
Bastian agrees now?)
> Bumping the ABI seems reasonable to me,
> even if that's effectively starting a mini-transition from a release
> point of view.
[...]
> > -Package: libdebian-installer4-dev
> > +Package: libdebian-installer5-dev
>
> Please don't!
You suggest to "bump the ABI" but not rename the packages? or...?
Maybe the argument above is convincing enough to just not bump the ABI?
> > --- a/include/debian-installer/release.h
> > +++ b/include/debian-installer/release.h
> > @@ -40,7 +40,7 @@ struct di_release
> >char *origin; /**< Origin field */
> >char *suite; /**< Suite field */
> >char *codename; /**< Codename field */
> > - di_hash_table *md5sum;/**< checksum fields,
> > includes di_release_file */
> > + di_hash_table *sha256;/**< checksum fields,
> > includes di_release_file */
> >di_mem_chunk *release_file_mem_chunk; /**< @internal */
> > };
>
> So md5sum goes away from the di_release struct…
Yes, the same as with di_package; that preserves ABI compatibility,
and getting rid of md5sum is also our intent.
>
> >
> > @@ -55,7 +55,7 @@ struct di_release_file
> > di_rstring key; /**< @internal */
> >};
> >unsigned int size;/**< size */
> > - char *sum[2]; /**< checksums, currently
> > md5 and sha1 */
> > + char *sum[2]; /**< checksums, currently
> > md5 and sha256 */
>
> … but is kept in the di_release_file one?
Right, this struct currently contains:
char *sum[0] -> dynamically allocated md5sum field
char *sum[1] -> dynamically allocated sha1 field
so that is what reverse-depends expect to be in those fields,
currently. To keep ABI comptibility, I should keep two items there.
The sha1 field is always empty, since that was removed from the Release
file. We could either:
1. replace sum[0] with sha256 and leave sum[1] empty; or
2. leave sum[0] containing md5 but replace sum[1] with sha256
My patch did 2. because it results in a smaller diff. But I like the
idea of doing 1. instead (we would drop the MD5- and SHA1-parsing code
and make absolutely sure nobody is still using those).
If I did 1. and we didn't bump the ABI, it should be easy to test:
* we'd patch+update only libdebian-installer, then test:
anna should abort the install, due to mismatching md5sums;
* then we'd patch anna, and it should all work again; one could
also delete the /usr/bin/md5sum symlink while testing.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
Bastian Blank wrote:
> This change breaks the existing ABI and therefor needs an ABI bump, but
> it is missing from the patch.
The attached patch tries to bump the soname to 5. This makes the diff
much larger, but the code changes are the same.
I think libdebian-installer-extra nowadays gets a soname bump at the
same time as libdebian-installer (whereas in the past it was possible to
set a different soname for each).
(If we really wanted, we could maybe avoid the ABI bump: no library
functions are being added/removed, only the name and meaning of a struct
member (a pointer, which remains the same length). The
dynamically-sized buffer it points to, would change from storing an MD5
to a SHA256 hash, and would only cause a regression where something is
still trying to validate MD5).
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
diff --git a/configure.ac b/configure.ac
index d559d64..2f276b8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -16,9 +16,9 @@ AS_IF([test "x$enable_check" != xno],[
])
AM_CONDITIONAL([ENABLE_CHECK],[test "x$enable_check" != xno])
-LIBRARY_VERSION_MAJOR=4
+LIBRARY_VERSION_MAJOR=5
LIBRARY_VERSION_MINOR=0
-LIBRARY_VERSION_REVISION=7
+LIBRARY_VERSION_REVISION=0
LIBRARY_VERSION="$LIBRARY_VERSION_MAJOR.$LIBRARY_VERSION_MINOR.$LIBRARY_VERSION_REVISION"
LIBRARY_VERSION_LIBTOOL="$LIBRARY_VERSION_MAJOR:$LIBRARY_VERSION_MINOR:$LIBRARY_VERSION_REVISION"
diff --git a/debian/changelog b/debian/changelog
index 3dd29e1..09c194e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,7 +1,18 @@
libdebian-installer (0.109) UNRELEASED; urgency=medium
+ [ Samuel Thibault ]
* Fix build with gcc-7. Closes: #853489
+ [ Steven Chamberlain ]
+ * Parse SHA256 fields instead of MD5Sum fields in Packages files.
+ * Parse SHA256 fields instead of (no longer existing) SHA1 fields in
+Release files.
+ * In structs di_release and di_package, add new sha256 member and
+remove the md5sum member (a backward-incompatible change, this will
+force reverse-dependencies to stop using MD5 for verification)
+(Closes: #856212).
+ * Bump soname as advised by Bastian Blank.
+
-- Samuel Thibault Tue, 31 Jan 2017 11:09:16 +0100
libdebian-installer (0.108) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index 0949fd9..f53f55c 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Standards-Version: 3.9.6
Vcs-Browser: https://anonscm.debian.org/cgit/d-i/libdebian-installer.git
Vcs-Git: https://anonscm.debian.org/git/d-i/libdebian-installer.git
-Package: libdebian-installer4
+Package: libdebian-installer5
Architecture: any
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
@@ -19,10 +19,10 @@ Description: Library of common debian-installer functions
working on debian-installer or building your own install system based
on debian-installer, then you probably don't need this library.
-Package: libdebian-installer4-dev
+Package: libdebian-installer5-dev
Section: libdevel
Architecture: any
-Depends: ${misc:Depends}, libdebian-installer4 (= ${binary:Version}), libdebian-installer-extra4 (= ${binary:Version})
+Depends: ${misc:Depends}, libdebian-installer5 (= ${binary:Version}), libdebian-installer-extra5 (= ${binary:Version})
Conflicts: libdebian-installer-dev
Provides: libdebian-installer-dev
Description: Library of common debian-installer functions
@@ -33,7 +33,7 @@ Description: Library of common debian-installer functions
.
This package contains files needed to do libdebian-installer development.
-Package: libdebian-installer4-udeb
+Package: libdebian-installer5-udeb
Package-Type: udeb
Section: debian-installer
Architecture: any
@@ -44,22 +44,22 @@ Description: Library of common debian-installer functions
working on debian-installer or building your own install system based
on debian-installer, then you probably don't need this library.
-Package: libdebian-installer-extra4
+Package: libdebian-installer-extra5
Architecture: any
Multi-Arch: same
-Depends: ${shlibs:Depends}, ${misc:Depends}, libdebian-installer4 (= ${binary:Version})
+Depends: ${shlibs:Depends}, ${misc:Depends}, libdebian-installer5 (= ${binary:Version})
Description: Library of some extra debian-installer functions
This library is used by debian-installer to perform common functions
such as logging messages and executing commands. If you aren't
working on debian-installer or building your own install system based
on debian-installer, then you probably don't need this library.
-Package: libdebian-installer-extra4-udeb
+Package: libdebian-installer-extra5-udeb
Package-Type: udeb
Section: debian-installer
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, libdebian-installer4-udeb (= ${binary:Version})
-Provides: libdebian-installer-extra4
+Depends: ${shlibs:Depends}, ${misc:Depends}, libdebian-installer5-udeb (= ${binary:Version})
+Provides: libdebian-ins
Bug#856211: anna: please implement SHA256 verification of .udeb files
Steven Chamberlain wrote:
> Attached is [...]
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
diff --git a/anna.c b/anna.c
index 4b68816..e03d34a 100644
--- a/anna.c
+++ b/anna.c
@@ -318,8 +318,8 @@ install_modules(di_packages *status, di_packages *packages) {
}
}
-if (! md5sum(package->md5sum, dest_file)) {
- di_log(DI_LOG_LEVEL_WARNING, "bad md5sum");
+if (! sha256sum(package->sha256, dest_file)) {
+ di_log(DI_LOG_LEVEL_WARNING, "bad sha256sum");
if (!quiet)
/* error handling may use a progress bar, so stop the current one */
debconf_progress_stop(debconf);
diff --git a/debian/changelog b/debian/changelog
index d6682ca..c885457 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+anna (1.58) UNRELEASED; urgency=medium
+
+ * Team upload.
+ * Replace md5sum verification with sha256sum (Closes: #856211).
+- (Build-)Depend on libdebian-installer soname version 5.
+
+ -- Steven Chamberlain Mon, 27 Feb 2017 15:13:37 +
+
anna (1.57) unstable; urgency=medium
[ Updated translations ]
diff --git a/debian/control b/debian/control
index def2af9..20ff1c3 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: debian-installer
Priority: standard
Maintainer: Debian Install System Team
Uploaders: Bastian Blank , Christian Perrier
-Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.15.7), libdebconfclient0-dev (>= 0.46), libdebian-installer4-dev (>= 0.41)
+Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.15.7), libdebconfclient0-dev (>= 0.46), libdebian-installer5-dev
Vcs-Browser: https://anonscm.debian.org/cgit/d-i/anna.git
Vcs-Git: https://anonscm.debian.org/git/d-i/anna.git
diff --git a/util.c b/util.c
index 39af3db..7d09cf8 100644
--- a/util.c
+++ b/util.c
@@ -224,23 +224,26 @@ int load_templates (di_packages *packages) {
}
#endif /* LOADTEMPLATES */
-/* Check whether the md5sum of file matches sum. If not, return 0. */
-int md5sum(const char *sum, const char *file) {
+/* Length of a SHA256 hash in hex representation */
+#define SHA256_HEX_LENGTH 64
+
+/* Check whether the sha256sum of file matches sum. If not, return 0. */
+int sha256sum(const char *sum, const char *file) {
FILE *fp;
char line[1024];
- /* Trivially true if the Packages file doesn't have md5sum lines */
+ /* Trivially true if the Packages file doesn't have sha256sum lines */
if (sum == NULL)
return 1;
- snprintf(line, sizeof(line), "/usr/bin/md5sum %s", file);
+ snprintf(line, sizeof(line), "/usr/bin/sha256sum %s", file);
fp = popen(line, "r");
if (fp == NULL)
return 0;
if (fgets(line, sizeof(line), fp) != NULL) {
pclose(fp);
- if (strlen(line) < 32)
+ if (strlen(line) < SHA256_HEX_LENGTH)
return 0;
- line[32] = '\0';
+ line[SHA256_HEX_LENGTH] = '\0';
return !strcmp(line, sum);
}
pclose(fp);
diff --git a/util.h b/util.h
index 71135e0..0c9e0a2 100644
--- a/util.h
+++ b/util.h
@@ -10,7 +10,7 @@ bool is_installed(di_package *p, di_packages *status);
size_t package_to_choice(di_package *package, char *buf, size_t size);
char *list_to_choices(di_package **packages, int c_values);
int get_package (di_package *package, char *dest);
-int md5sum(const char* sum, const char *file);
+int sha256sum(const char* sum, const char *file);
int skip_package(di_package *p);
int package_name_compare(const void *v1, const void *v2);
void take_includes(di_packages *packages);
signature.asc
Description: Digital signature
Bug#856211: anna: please implement SHA256 verification of .udeb files
Control: tags -1 + patch Hi, Attached is a minimal patch intended to implement SHA256 verification. It would depend on libdebian-installer being patched first (#856210) and bumping the soname to 5. "#define SHA256_HEX_LENGTH 64" is made explicit as possible so that one remembers to increase it if changing SHA256 to SHA512 in the future. A more thorough rework of this code might store the hash type (as an enum) and length, in the di_package struct instead. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856211: anna: please implement SHA256 verification of .udeb files
Cyril Brulebois wrote: > IIRC MD5sum field was kept (as in: added > back) because debian-cd needs it at the moment, which partly explains why this > wasn't fixed earlier. I think backward-compatibility would have been okay as long as *either*: * the archive published Release files with old+new hash algorithms; or * the utilities consuming it, supported the old/new hash algorithms; but here we had done both of those things, which allowed for a downgrade to go unnoticed. I think right now it is easier to fix anna+cdebootstrap than debian-cd? > but referencing places where stuff like parsing happens > (Release, Packages, etc.), and where checkums are used, Yesss, but only if someone updated that documentation with what the code is doing. Removal of SHA1 in Relases had an action-at-a-distance effect on cdebootstrap, so it wouldn't be clear that the documentation needed to change then. In the ideal world, the code itself would be the clear, authoritative reference of what it is doing. I wish that we can remove all references to md5 and sha1 there. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856211: anna: please implement SHA256 verification of .udeb files
Hello! Cyril Brulebois wrote: > AFAICT net-retriever does the fetching and checking work? Mayyybe... Although with http://ftp.de.debian.org/debian/dists/testing/main/installer-i386/20170127/images/netboot/mini.iso I observed md5sum and sha256sum only being executed as indicated in the attached log. Regards, -- Steven Chamberlain ste...@pyro.eu.org /usr/bin/sha256sum /tmp/net-retriever-1817-Packages /usr/bin/sha256sum /tmp/net-retriever-1872-Packages /usr/bin/sha256sum /tmp/net-retriever-1872-Packages /usr/bin/sha256sum /tmp/net-retriever-1872-Packages /usr/bin/md5sum /var/cache/anna/apt-mirror-setup_0.123_all.udeb /usr/bin/md5sum /var/cache/anna/apt-setup-udeb_0.123_i386.udeb /usr/bin/md5sum /var/cache/anna/base-installer_1.167_all.udeb /usr/bin/md5sum /var/cache/anna/bootstrap-base_1.167_i386.udeb /usr/bin/md5sum /var/cache/anna/btrfs-progs-udeb_4.7.3-1_i386.udeb /usr/bin/md5sum /var/cache/anna/clock-setup_0.132_i386.udeb /usr/bin/md5sum /var/cache/anna/di-utils-mapdevfs_1.117_i386.udeb /usr/bin/md5sum /var/cache/anna/debootstrap-udeb_1.0.88_all.udeb /usr/bin/md5sum /var/cache/anna/dosfstools-udeb_4.1-1_i386.udeb /usr/bin/md5sum /var/cache/anna/e2fsprogs-udeb_1.43.4-2_i386.udeb /usr/bin/md5sum /var/cache/anna/elilo-installer_1.31_i386.udeb /usr/bin/md5sum /var/cache/anna/finish-install_2.75_all.udeb /usr/bin/md5sum /var/cache/anna/fuse-udeb_2.9.7-1_i386.udeb /usr/bin/md5sum /var/cache/anna/libfuse2-udeb_2.9.7-1_i386.udeb /usr/bin/md5sum /var/cache/anna/grub-installer_1.137_i386.udeb /usr/bin/md5sum /var/cache/anna/grub-mount-udeb_2.02~beta3-5_i386.udeb /usr/bin/md5sum /var/cache/anna/disk-detect_1.121_i386.udeb /usr/bin/md5sum /var/cache/anna/installation-locale_1.7_i386.udeb /usr/bin/md5sum /var/cache/anna/jfsutils-udeb_1.1.15-3_i386.udeb /usr/bin/md5sum /var/cache/anna/kickseed-common_0.62_all.udeb /usr/bin/md5sum /var/cache/anna/libbsd0-udeb_0.8.3-1_i386.udeb /usr/bin/md5sum /var/cache/anna/lilo-installer_1.52_i386.udeb /usr/bin/md5sum /var/cache/anna/ata-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/btrfs-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/cdrom-core-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/efi-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/ext4-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/fat-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/firewire-core-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/isofs-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/jfs-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/kernel-image-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/loop-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/md-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/nic-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/nic-pcmcia-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/nic-shared-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/nic-usb-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/nic-wireless-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/pata-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/pcmcia-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/pcmcia-storage-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/sata-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/scsi-core-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/scsi-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/usb-storage-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/xfs-modules-4.9.0-1-686-di_4.9.6-3_i386.udeb /usr/bin/md5sum /var/cache/anna/dmsetup-udeb_1.02.137-1_i386.udeb /usr/bin/md5sum /var/cache/anna/libdevmapper1.02.1-udeb_1.02.137-1_i386.udeb /usr/bin/md5sum /var/cache/anna/liblzo2-2-udeb_2.08-1.2_i386.udeb /usr/bin/md5sum /var/cache/anna/mdadm-udeb_3.4-4_i386.udeb /usr/bin/md5sum /var/cache/anna/network-console_1.62_i386.udeb /usr/bin/md5sum /var/cache/anna/nobootloader_1.47_all.udeb /usr/bin/md5sum /var/cache/anna/ntfs-3g-udeb_2016.2.22AR.1-4_i386.udeb /usr/bin/md5sum /var/cache/anna/open-iscsi-udeb_2.0.874-2_i386.udeb /usr/bin/md5sum /var/cache/anna/libisns-nocrypto0-udeb_0.97-1_i386.udeb /usr/bin/md5sum /var/cache/anna/openssh-server-udeb_7.4p1-6_i386.udeb /usr/bin/md5sum /var/cache/anna/os-prober-udeb_1.74_i386.udeb /usr/bin/md5sum /var/cache/anna/partconf-find-partitions_1.50_i386.udeb /usr/bin/md5sum /var/cache/anna/libparted-fs-resize0-udeb_3.2-17_i386.udeb /usr/bin/md5sum /var/cache/anna/libparted2-udeb_3.2-17_i386.udeb /usr/bin/md5sum /var/cache/anna/partman-auto_137_i386.udeb /usr/bin/md5
Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
Hi, Bastian Blank wrote: > This change breaks the existing ABI and therefor needs an ABI bump, but > it is missing from the patch. I agree, that should be done. Thanks. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856212: cdebootstrap: please implement SHA256 verification of .deb files
Hi, Bastian Blank wrote: > I was not able to provide a real fix as I'm rather time constrained. Don't worry, I'm prepared to write patches. But I wonder: * is it okay to drop MD5 support, when implementing SHA256? * must we fix this before the stretch release? or otherwise, would it be possible to make such a big change in a stable point release? > However please provide this information, as I only found something with > about 2^120 for preimage attacks on MD5, which is still not fesable in > real live. Last time I brought up the topic, that argument was given. But maybe it's the wrong approach to ask "are we *sure* MD5 is broken and we must replace it?". We need to make a prediction that lasts the supported lifetime of stretch (until 2022?); and some adversaries do not reveal their capabilities. It's actually kind of bizarre that we've published SHA256 sums in the archive since 2007 and *still* don't use them here. I think there is a greater risk that we forget, or be too lazy, than we do this 'too soon'. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
With that patch, reverse-deps anna and cdebootstrap shall FTBFS with:
| gcc -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -g -O2
-fdebug-prefix-map=/home/steven/git/anna=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -Wall -W -ggdb -Wdate-time -D_FORTIFY_SOURCE=2
-D_GNU_SOURCE -c -o anna.o anna.c
| anna.c: In function ‘install_modules’:
| anna.c:321:25: error: ‘di_package {aka struct di_package}’ has no member
named ‘md5sum’
| if (! md5sum(package->md5sum, dest_file)) {
| ^~
| gcc -DHAVE_CONFIG_H -I. -I../../src -I.. -I../../include -Wdate-time
-D_FORTIFY_SOURCE=2 -g -O2
-fdebug-prefix-map=/home/steven/git/cdebootstrap-0.7.6=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -std=gnu99 -c -o gpg.o ../../src/gpg.c
| ../../src/check.c: In function ‘check_deb’:
| ../../src/check.c:61:40: error: ‘di_package {aka struct di_package}’ has no
member named ‘md5sum’
|return check_sum (target, "md5sum", p->md5sum, message);
| ^~
| ../../src/check.c: In function ‘check_packages’:
| ../../src/check.c:75:35: error: ‘di_release {aka struct di_release}’ has no
member named ‘md5sum’
|item = di_hash_table_lookup (rel->md5sum, &key);
|^~
so it should be quite clear that they must implement a new hashing
algorithm; and this makes absolutely sure they are not still using MD5
unintentionally (which was the case in #856215).
If my libdebian-installer patch is okay, I will submit the patches for
anna and cdebootstrap (bugs are already filed against them). Hopefully
no other reverse-dependencies would be affected (because they do not use
the md5sums field, and the struct size is not changing); though if they
do use, I'd prefer they FTBFS so that we find out.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
Control: tags -1 + patch Hi, The regression in Bug#856215 in cdebootstrap: "since SHA1 removal from Release file, only MD5sums are used" could only be fixed by adding support for the SHA256 fields. An open question is whether to preserve any support for MD5. Keeping it would: + reduce potential for breakage (in case MD5 is "good enough" for some use-case or SHA256 is still impractical) + allow verifiers to check both MD5 *and* SHA256, for even stronger authentication in case one or both algorithms are broken - add complexity Otherwise, dropping MD5 entirely would: * break reverse-dependencies (hopefully just anna, cdebootstrap) thus *forcing* us to stop using MD5 there, and implement SHA256 I've attached only the most minimal patch to allow reverse-depends do implement SHA256. They must adapt to the new names of struct members *and* remember that the hash length is now different. (The hash data is stored in variable-length fields but the length is not recorded in the structs, and the has is denoted by a magic number not an enum; that could be made better, but requiring a much larger diff). A follow-up commit should extend the testsuite to check parsing of the SHA256 fields; that also would result in a larger diff however. Regards, -- Steven Chamberlain ste...@pyro.eu.org diff --git a/debian/changelog b/debian/changelog index 3dd29e1..1b7fcd8 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,7 +1,16 @@ libdebian-installer (0.109) UNRELEASED; urgency=medium + [ Samuel Thibault ] * Fix build with gcc-7. Closes: #853489 + [ Steven Chamberlain ] + * Parse SHA256 fields instead of MD5Sum fields in Packages files. + * Parse SHA256 fields instead of (no longer existing) SHA1 fields in +Release files. + * In structs di_release and di_package, add new sha256 member and +remove the md5sum member (a backward-incompatible change, this will +force reverse-dependencies to stop using MD5 for verification). + -- Samuel Thibault Tue, 31 Jan 2017 11:09:16 +0100 libdebian-installer (0.108) unstable; urgency=medium diff --git a/include/debian-installer/package.h b/include/debian-installer/package.h index 72d7444..e1f699d 100644 --- a/include/debian-installer/package.h +++ b/include/debian-installer/package.h @@ -112,7 +112,7 @@ struct di_package di_slist depends; /**< Any different dependency types */ char *filename; /**< Filename field */ size_t size; /**< Size field */ - char *md5sum; /**< MD5Sum field */ + char *sha256; /**< SHA256 field */ char *short_description; /**< Description field, first part*/ char *description;/**< Description field, second part */ unsigned int resolver;/**< @internal */ diff --git a/include/debian-installer/package_internal.h b/include/debian-installer/package_internal.h index f6357d1..d410ce2 100644 --- a/include/debian-installer/package_internal.h +++ b/include/debian-installer/package_internal.h @@ -52,7 +52,7 @@ const di_parser_fieldinfo internal_di_package_parser_field_enhances, internal_di_package_parser_field_filename, internal_di_package_parser_field_size, - internal_di_package_parser_field_md5sum, + internal_di_package_parser_field_sha256, internal_di_package_parser_field_description; /** diff --git a/include/debian-installer/release.h b/include/debian-installer/release.h index 223a4f8..8e3c572 100644 --- a/include/debian-installer/release.h +++ b/include/debian-installer/release.h @@ -40,7 +40,7 @@ struct di_release char *origin; /**< Origin field */ char *suite; /**< Suite field */ char *codename; /**< Codename field */ - di_hash_table *md5sum;/**< checksum fields, includes di_release_file */ + di_hash_table *sha256;/**< checksum fields, includes di_release_file */ di_mem_chunk *release_file_mem_chunk; /**< @internal */ }; @@ -55,7 +55,7 @@ struct di_release_file di_rstring key; /**< @internal */ }; unsigned int size;/**< size */ - char *sum[2]; /**< checksums, currently md5 and sha1 */ + char *sum[2]; /**< checksums, currently md5 and sha256 */ }; di_release *di_release_alloc (void); diff --git a/src/package.c b/src/package.c index 653b5dd..82c7653 100644 --- a/src/package.c +++ b/src/package.c @@ -38,7 +38,7 @@ void di_package_destroy (di_package *package) di_free (package->architecture); di_fr
Bug#856215: cdebootstrap: since SHA1 removal from Release file, only MD5sums are used
Source: cdebootstrap Version: 0.5.8 Severity: grave Tags: security stretch sid X-Debbugs-Cc: secur...@debian.org User: debian-rele...@lists.debian.org Usertags: bsp-2017-02-de-Berlin Hi, The current Debian 'testing' release - the upcoming 'stretch' release candidate - removed the SHA1 sums from the Release file. That was intended to deprecate it in favour of SHA256. An unintended consequence is that cdebootstrap, when SHA1 sums are unavailable, falls back to using only the MD5Sum field instead: http://sources.debian.net/src/cdebootstrap/0.7.6/src/check.c/#L79 if (item->sum[1]) return check_sum (target, "sha1sum", item->sum[1], buf_name); if (item->sum[0]) return check_sum (target, "md5sum", item->sum[0], buf_name); Further context and an overview of related bugs will be published at: https://wiki.debian.org/InstallerDebacle Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856213: cdebootstrap: SHA1 verification truncates hash from 160 to 128 bits
Source: cdebootstrap Version: 0.5.8 Severity: grave Tags: security X-Debbugs-Cc: secur...@debian.org User: debian-rele...@lists.debian.org Usertags: bsp-2017-02-de-Berlin Control: block 856212 by -1 Hi, cdebootstrap implemented in version 0.5.8 (2011) verification of the Packages files using the SHA1 field of the Release file. That first featured in the installer of the 'wheezy' release (2013). But whereas md5sum yields a 32-byte hex string, sha1sum yields a 40-byte hex string. cdebootstrap did not consider this, and so it would only compare the first 32 bytes of the hex string against the expected value (effectively truncating the SHA1 hash from 160 to only 128 bits): http://sources.debian.net/src/cdebootstrap/0.7.6/src/check.c/#L54 if (item->sum[1]) return check_sum (target, "sha256sum", item->sum[1], buf_name); ... if (!strncmp (buf, sum, 32)) Further context and an overview of related bugs will be published at: https://wiki.debian.org/InstallerDebacle Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856212: cdebootstrap: please implement SHA256 verification of .deb files
Source: cdebootstrap Version: 0.7.6 Severity: grave Tags: security X-Debbugs-Cc: secur...@debian.org User: debian-rele...@lists.debian.org Usertags: bsp-2017-02-de-Berlin Control: block -1 by 856210 Hi, To date, cdebootstrap still only implements MD5 verification of .deb files, despite its formal deprecation as a digital signature algorithm by RFC6151 (2011) and recommendations of academic literature years prior. The files are typically downloaded via insecure HTTP transport, so the checksum verification is critical for the security of the installed system. stretch is expected to be a supported release until 2022. So I'm tentatively filing this bug as RC-severity. Further context and an overview of related bugs will be published at: https://wiki.debian.org/InstallerDebacle Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856211: anna: please implement SHA256 verification of .udeb files
Source: anna Version: 1.57 Severity: grave Tags: security X-Debbugs-Cc: secur...@debian.org User: debian-rele...@lists.debian.org Usertags: bsp-2017-02-de-Berlin Control: block -1 by 856210 Hi, To date, anna still only implements MD5 verification of .udeb files, despite its formal deprecation as a digital signature algorithm by RFC6151 (2011) and recommendations of academic literature years prior. The files are typically downloaded via insecure HTTP transport, so the checksum verification is critical for the security of the installed system. stretch is expected to be a supported release until 2022. So I'm tentatively filing this bug as RC-severity. Further context and an overview of related bugs will be published at: https://wiki.debian.org/InstallerDebacle Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
Source: libdebian-installer Version: 0.108 Severity: serious Tags: security X-Debbugs-Cc: secur...@debian.org User: debian-rele...@lists.debian.org Usertags: bsp-2017-02-de-Berlin Hi, The 'etch' release (2007) added to the Release file, a field for SHA256 sums to authenticate Packages files. But to date, libdebian-installer does not parse it, so anna (which fetches .udeb installer component) and cdebootstrap (which fetches .deb base system packages) can not yet verify the SHA256 sums. http://sources.debian.net/src/libdebian-installer/0.108/include/debian-installer/release.h/#L43 http://sources.debian.net/src/libdebian-installer/0.108/include/debian-installer/release.h/#L58 http://sources.debian.net/src/libdebian-installer/0.108/include/debian-installer/package.h/#L115 Further context and an overview of related bugs will be published at: https://wiki.debian.org/InstallerDebacle This bug is not itself RC, but it will be a blocking issue for RC bugs I'm about to file. I intend to submit a patch for this shortly. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#853153: It can't start by a segmentation fault
Control: severity -1 important Hello, (I'm downgrading severity of this bug as a formality, since it doesn't affect _all_ users, and didn't cause any data loss or affect anything other than Xorg itself). Jonny wrote: > it was not able to start at all after I was rebuilt in xorg-server after 1.19. > It can start in xserver-xorg-core 2:1.18.4-2 and > xserver-xorg-video-siliconmiton 1:1.7.8-2. Exactly what graphics hardware do you have? Please could you show relevant output from dmesg/lspci describing what it is? Or even better, a Xorg.log for the version that works correctly? Actually your log doesn't seem to describe any issue with graphics, but rather something to do with dbus, either crashed or not running: | (EE) dbus-core: error connecting to system bus: | org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket | /var/run/dbus/system_bus_socket: No such file or directory) Did you try rebooting the machine before starting Xorg? Perhaps you could find something relevant in your logs with: $ cd /var/log && sudo grep dbus dpkg.log syslog Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#845105: mk-freebsd: bsd.cpu.mk sets -mfloat-abi=softfp on armhf
Adrian Bunk wrote: > The root cause of this ctfutils FTBFS is that -mfloat-abi=softfp > is passed to the compiler on armhf, which seems to come from > /usr/share/mk-freebsd/bsd.cpu.mk Thanks for pointing that out! All arm* architectures were being mapped to the FreeBSD MACHINE_TYPE "armv6" which targets the soft-float ABI. I've defined a new MACHINE_TYPE "armv6hf" and mapped armhf to that instead (as well as kfreebsd-armhf, for when it exists). ctfutils was given back and rebuild successfully after this change. armel should work as before. We don't yet have arm64 support; that will happen in time. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#837289: kfreebsd-10: FTBFS: objcopy:linux32_vdso.so: Invalid bfd target
severity 837289 important thanks Hi, Lucas Nussbaum wrote: > Severity: serious > Justification: FTBFS on amd64 This package's Architecture: fields do not include [linux-]amd64, so I think this is not release-critical. It is desirable though that we can fix it to become possible (again) to build it on linux. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#770130: gnome-shell: crashes with "Failed to create texture 2d"
Hi, FWIW I've seen this same error reproduced on ATI Radeon R200 hardware in an old IBM Thinkpad: | gnome-session[7213]: (gnome-shell:7314): Cogl-ERROR **: Failed to create texture 2d due to size/format constraints | gnome-session[7213]: x-session-manager[7213]: WARNING: Application 'gnome-shell.desktop' killed by signal 5 gdm3 seemed to work, but the 'cog wheel' icon to choose a session type, was not rendered. (Probably it tries to use a non-power-of-two texture, which this hardware does not support?) Trying to start GNOME or GNOME Classic, the above error is fatal, and causes a "fail-whale" with only an option to log out. Probably GNOME is not suitable for that hardware, then. It was a really unfortunate experience for the (first-time) user, though. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#840468: mame: FTBFS[arm64]: immediate value out of range 0 to 63
Package: src:mame
Version: 0.178-1
Severity: serious
Justification: FTBFS, but built successfully in the past
Hi,
On linux-arm64, mame since 0.176-3 FTBFS, because:
https://buildd.debian.org/status/fetch.php?pkg=mame&arch=arm64&ver=0.178-1&stamp=1475578747
| Compiling src/emu/emumem.cpp...
| g++ -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. -fPIE -fstack-protector-strong
-Wformat -Werror=format-security -g0 -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=.
-fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -MMD -MP -MP -DNDEBUG
-DCRLF=2 -DLSB_FIRST -DXMD_H -DFLAC__NO_DLL -DMAME_NOASM -DLUA_COMPAT_ALL
-DLUA_COMPAT_5_1 -DLUA_COMPAT_5_2 -DPTR64=1 -DNO_AFFINITY_NP
-I../../../../../src/osd -I../../../../../src/emu -I../../../../../src/lib
-I../../../../../src/lib/util -I../../../../../3rdparty
-I../../../../generated/emu -I../../../../generated/emu/layout
-I../../../../../scripts/src -pipe -Wno-deprecated-declarations -O3
-fno-strict-aliasing -mabi=lp64 -Wno-unknown-pragmas -Wall -Wcast-align -Wundef
-Wformat-security -Wwrite-strings -Wno-sign-compare -Wno-conversion
-Wno-unused-result -Wno-array-bounds -Wno-cast-align -x c++ -std=c++14
-Woverloaded-virtual -Wsuggest-override -flifetime-dse=1 -include obj
/Release/emu.h -o "obj/Release/src/emu/emumem.o" -c
"../../../../../src/emu/emumem.cpp"
| {standard input}:28638: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,64,16'
| {standard input}:28643: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,80,16'
| {standard input}:28648: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,96,16'
| {standard input}:28653: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,112,16'
| {standard input}:28658: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,128,16'
| {standard input}:28663: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,144,16'
| {standard input}:28668: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,160,16'
| {standard input}:28673: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,176,16'
| {standard input}:28678: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,192,16'
| {standard input}:28683: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,208,16'
| {standard input}:28688: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,224,16'
| {standard input}:31708: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,64,32'
| {standard input}:31713: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,96,32'
| {standard input}:31718: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,128,32'
| {standard input}:31723: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,160,32'
| {standard input}:31728: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,192,32'
| {standard input}:32454: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,64,16'
| {standard input}:32459: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,80,16'
| {standard input}:32464: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,96,16'
| {standard input}:32469: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,112,16'
| {standard input}:32474: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,128,16'
| {standard input}:32479: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,144,16'
| {standard input}:32484: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,160,16'
| {standard input}:32489: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,176,16'
| {standard input}:32494: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,192,16'
| {standard input}:32499: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,208,16'
| {standard input}:32504: Error: immediate value out of range 0 to 63 at
operand 3 -- `ubfx x0,x2,224,16'
| make[4]: *** [obj/Release/src/emu/emumem.o] Error 1
| Makefile:46: recipe for target 'emu' failed
| make[3]: *** [emu] Error 2
| make[3]: *** Waiting for unfinished jobs
ubfx is the ARM Thumb-2 instruction for "unsigned bit field extract".
I don't really know what that means, but notice the operands are
increasing by 16 each time, and expected values are in the range
[0..63]. So I would guess the problem relates to this 16x64 array in
src/emu/emumem.cpp:
201 static char *core_i64_hex_format(UINT64 value, UINT8 mindigits)
202 {
203 static char buffer[16][64];
Thanks.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Arch
Bug#825268: zfsutils,zutils: error when trying to install together
retitle 825268 zfsutils,zutils: error when trying to install together thanks Hi, Daniel Baumann wrote: > how about renaming ztest in zfsutils to zfstest? That sounds good to me. We'll rename it on kfreebsd if you want to do the same on linux. In the Debian archive, I can't find anything using it; it's really a standalone tool for developers (or could make a good Debian c-i test someday). Ironically, there is the same name conflict in upstream FreeBSD: http://www.freebsd.org/cgi/man.cgi?query=ztest (the only manpage found, refers to zutils' ztest). Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#824605: kfreebsd-10: CVE-2016-1887: Incorrect argument handling in sendmsg(2)
Package: src:kfreebsd-10 Version: 10.1~svn274115-4+kbsd8u3 Severity: grave Tags: security https://security.FreeBSD.org/advisories/FreeBSD-SA-16:19.sendmsg.asc Incorrect argument handling in the socket code allows malicious local user to overwrite large portion of the kernel memory. This affects 10.1 in sid and jessie; 10.3 and 11.1 in experimental. It was not reported to affect 9.0. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 10.1-0-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#824604: kfreebsd-10: CVE-2016-1886: Buffer overflow in keyboard driver
Package: src:kfreebsd-10 Version: 10.1~svn274115-4+kbsd8u3 Severity: grave Tags: security https://security.FreeBSD.org/advisories/FreeBSD-SA-16:18.atkbd.asc Incorrect signedness comparison in the ioctl(2) handler allows a malicious local user to overwrite a portion of the kernel memory. This affects 10.1 in sid and jessie; 9.0 in wheezy; 10.3 and 11.1 in experimental. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 10.1-0-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#820947: marked as pending
tag 820947 pending thanks Hello, Bug #820947 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://git.debian.org/?p=pkg-samba/samba.git;a=commitdiff;h=6e1e21e --- commit 6e1e21e8e6a41d5267d41519bccee87011684b6c Author: Salvatore Bonaccorso Date: Thu Apr 14 06:56:06 2016 +0200 Move libraries back to samba-libs libsmbd-base.so.0, process_model/*.so and libprocess-model.so.0 libraries back to the samba-libs binary package. (Closes: #820947) diff --git a/debian/changelog b/debian/changelog index a58f042..3cff08e 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,12 @@ +samba (2:4.2.10+dfsg-0+deb8u2) UNRELEASED; urgency=high + + * Non-maintainer upload by the Security Team. + * Move libraries back to samba-libs +libsmbd-base.so.0, process_model/*.so and libprocess-model.so.0 +libraries back to the samba-libs binary package. (Closes: #820947) + + -- Salvatore Bonaccorso Thu, 14 Apr 2016 06:56:06 +0200 + samba (2:4.2.10+dfsg-0+deb8u1) jessie-security; urgency=high [ Jelmer Vernooij ]
Bug#725629: vice: racy build
Tobias Frost wrote: > Now I cannot reproduce the compile problem... Did you build again from the same tree? There is a circular dependency of: * autoreconf generates configure from configure.ac * configure generates Makefile from Makefile.am * Makefile has a configure.ac rule to rebuild configure.ac from (patched) configure.proto So if you build a second time, autoreconf takes the configure.ac now derived from (patched) configure.proto I've attached a patch for this particular madness. That, in combination with Andreas' patch set, seems to get this building reliably on kfreebsd. Thanks! (There is still other madness, such as sub-makes seemingly hiding stdout, only showing stderr and not the actual commands run). Regards, -- Steven Chamberlain ste...@pyro.eu.org --- debian/rules.orig 2016-04-11 20:28:53.529023000 +0100 +++ debian/rules 2016-04-11 21:34:32.951752497 +0100 @@ -36,6 +36,12 @@ .PHONY: build build: + # These files in the original source are not used + rm -f configure configure.ac + + sed "s/AM_CONFIG_HEADER/AC_CONFIG_HEADERS/g" \ + < configure.proto > configure.ac + dh $@ --with autoreconf %: signature.asc Description: Digital signature
Bug#725629: vice: racy build
László Böszörményi (GCS) wrote: > Please see Makefile.am: > -- cut -- > $(top_srcdir)/configure.ac: $(top_srcdir)/configure.proto > $(am__cd) $(srcdir) && $(SHELL) autogen.sh > -- cut -- > > As such, for configure.ac autogen.sh is used, which contains this: > -- cut -- > if test x"$configure_needs_ac" = "xyes"; then > sed s/AM_CONFIG_HEADER/AC_CONFIG_HEADERS/g > configure.ac > else > cp configure.proto configure.ac > fi > -- cut -- > > This means configure.proto just copied over configure.ac or 'sed' is > used for substitution to generate configure.ac from the former. This > means any patching of configure.ac will be lost and thus not needed. I wish you could see the horror and anguish in my facial expressions. Why did it become so convoluted!? There are three copies of configure in the upstream source... plus there are warnings referring to a configure.in also. > That's correct and previously it worked. Please see that 2.4.26 built > on kfreebsd-i386 and on kfreebsd-amd64 already. Only when it was > binNMUed failed on kfreebsd-i386. I think it was only an accident that it worked before. See in https://buildd.debian.org/status/fetch.php?pkg=vice&arch=amd64&ver=2.4.dfsg%2B2.4.26-1%2Bb1&stamp=1460051005 the first time that configure ran, it was based on the unpatched configure.ac (which generates a lot of warnings about AC_* macros) : | checking for unistd.h... (cached) yes | checking sys/io.h usability... yes | checking sys/io.h presence... yes | checking for sys/io.h... yes | checking machine/pio.h usability... no | checking machine/pio.h presence... no | checking for machine/pio.h... no | checking machine/cpufunc.h usability... yes | checking machine/cpufunc.h presence... yes | checking for machine/cpufunc.h... yes | checking for ieee1284_find_ports in -lieee1284... yes and the second time it ran, it used the patched configure.proto, not checking for machine/cpufunc.h any more: | checking for unistd.h... (cached) yes | checking sys/io.h usability... yes | checking sys/io.h presence... yes | checking for sys/io.h... yes | checking machine/pio.h usability... no | checking machine/pio.h presence... no | checking for machine/pio.h... no | checking for ieee1284_find_ports in -lieee1284... yes And now of course the build only runs configure once, so it uses only the unpatched configure.ac Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#725629: vice: racy build
Hi! Tobias Frost wrote: > /usr/include/i386-kfreebsd-gnu/machine/cpufunc.h:42:2: error: #error > "This header must not be used in combination with ." > #error "This header must not be used in combination with ." I notice there is already a patch for this called kfreebsd_no_machine_cpufunc.h.patch although, you still had it applied for that build: > dpkg-buildpackage: host architecture kfreebsd-i386 > dpkg-source: info: applying correct_html_documentation_path_in_manpage.patch > dpkg-source: info: applying kfreebsd_no_machine_cpufunc.h.patch > dpkg-source: info: applying revert_upstream_lib64.patch > dpkg-source: info: applying fix-timestamp-race.patch It patches vice-2.3.dfsg/configure.proto (what is that?) and not configure.ac; and I imagine the latter one is being used now. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#820105: xscreensaver: please consider removal from sid
Package: xscreensaver Version: 5.34-1 Severity: grave Tags: upstream Hi, The upstream maintainer of xscreensaver has explicitly asked Debian to stop shipping it, which is a shame of course: https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/ It *is* still a free software project, based on freely-licensed works of many authors. Debian obviously may choose to ship it in any case, and I'm sure it will continue to do so in wheezy-lts and jessie. Removal from sid did sound extreme to me at first, but going forward, software projects do need an upstream maintainer, and currently he chooses to be hostile: Bug #819703 was a deliberate annoyance / anti-feature that impacted many of our users, and will create work for the package maintainer and stable release managers to resolve. Even if it is only minor, it would not stand if Debian allowed that sort of thing to proliferate in all software in its stable releases. CVEs are not filed for security bugs and code commits don't seem to be split out individually in any public repository, making security support in stable releases problematic. (similar to the Oracle-MySQL situation) Newer upstream versions add advertising for the upstream maintainer's commercial ventures. The logos of DNA Lounge, DNA Pizza and Codeword seem likely to be non-free by the DFSG. Their removal could further incense the upstream maintainer, more-so than removing the package. Thanks for your consideration. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 10.1-0-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
Bug#819890: haskell-http2: FTBFS on armel buildds (was: Re: Please give back haskell-http2 on armel)
Package: haskell-http2 Version: 1.5.3-2 Severity: serious X-Debbugs-Cc: debian-...@lists.debian.org Hi, Wookey wrote: > +++ Steven Chamberlain [2016-04-01 10:31 +0100]: > > Currently haskell-http2 FTBFS on only armel: > > https://buildd.debian.org/status/package.php?p=haskell-http2&suite=unstable > > delaying the package's testing migration and keeping many reverse-deps > > BD-Uninstallable on armel. > > > > More recently than that it has successfully built: > > https://tests.reproducible-builds.org/rbuild/unstable/armhf/haskell-http2_1.5.3-2.rbuild.log > > > > Therefore, please could it be given back for another build attempt? > > > > gb haskell-http2_1.5.3-2 . armel > > Seems a reasonable request. > done Thanks; it didn't work though. Please could arm porters take a look? The reproducible-builds log shows the test suite passing, whereas on the buildds one test failed, on both build attempts. There are a dozen or so packages BD-Uninstallable on armel due to this. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#814631: Processed: notfixed 800780 in 1.5.24-1, notfixed 814631 in 1:1.7.8-1, notfound 816075 in 3.2.1-1 ...
Oh sorry, I've just noticed the comment: Debian Bug Tracking System wrote: > # unconfuse bts Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#814631: Processed: notfixed 800780 in 1.5.24-1, notfixed 814631 in 1:1.7.8-1, notfound 816075 in 3.2.1-1 ...
Hi Andreas,
Debian Bug Tracking System wrote:
> > notfixed 814631 1:1.7.8-1
> Bug #814631 {Done: Steven Chamberlain }
> [src:xserver-xorg-video-siliconmotion] xserver-xorg-video-siliconmotion:
> FTBFS: src/smi.h:224:5: error: unknown type name 'IOADDRESS'
> No longer marked as fixed in versions 1:1.7.8-1.
Does it still FTBFS for you?
There is a recent log of it building here:
https://tests.reproducible-builds.org/rbuild/unstable/amd64/xserver-xorg-video-siliconmotion_1.7.8-1.rbuild.log
Do you have a log of the FTBFS to compare with?
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Bug#818426: kfreebsd-10: CVE-2016-1885: incorrect argument validation in sysarch(2)
Package: src:kfreebsd-10 Version: 10.1~svn274115-4+kbsd8u2 Severity: grave Tags: upstream patch A local unprivileged user could trigger a kernel panic or DoS attack on kfreebsd-amd64 via sysarch(2) sysctls: https://security.freebsd.org/advisories/FreeBSD-SA-16:15.sysarch.asc This affects kfreebsd-10, and also kfreebsd-9 in wheezy. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 10.1-0-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
Bug#720378: cctools: FTBFS on non-linux
severity 720378 important user debian-...@lists.debian.org usertags 720378 + kfreebsd thanks Hi, Sorry, I did not see this bug. It should have been downgraded because kfreebsd and hurd are not release architectures. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#811238: FTBFS: error: ld returned 1 exit status
Version: 10.3~svn296373-1
Bug#810975: 4store: FTBFS on arm64, kfreebsd-any: stat.h:76:21: error: field 'st_atim' has incomplete type
tags 810975 + patch thanks Hi, Andreas Beckmann wrote: > gcc -DHAVE_CONFIG_H -I. -I../.. -D_FORTIFY_SOURCE=2 -std=gnu99 > -fno-strict-aliasing -Wall -g -O2 -I./ -I../ -DGIT_REV="\"v1.1.6+20151109\"" > -I/usr/include/glib-2.0 -I/usr/lib/aarch64-linux-gnu/glib-2.0/include > -I/usr/include/raptor2 -I/usr/include/rasqal -I/usr/include/raptor2 > -I/usr/include/libxml2 `pcre-config --cflags` -g -O2 -fstack-protector-strong > -Wformat -Werror=format-security -Wall -c -o filter-datatypes.o > filter-datatypes.c > In file included from /usr/include/fcntl.h:68:0, > from ../common/params.h:4, > from query-datatypes.h:8, > from filter.h:4, > from filter-datatypes.c:28: > /usr/include/aarch64-linux-gnu/bits/stat.h:76:21: error: field 'st_atim' has > incomplete type > struct timespec st_atim; /* Time of last access. */ > ^ > /usr/include/aarch64-linux-gnu/bits/stat.h:77:21: error: field 'st_mtim' has > incomplete type > struct timespec st_mtim; /* Time of last modification. */ > ^ > /usr/include/aarch64-linux-gnu/bits/stat.h:78:21: error: field 'st_ctim' has > incomplete type > struct timespec st_ctim; /* Time of last status change. */ > ^ What's going wrong here is, filter-datatypes.c includes and at that time, __need_timespec is not defined: #define _XOPEN_SOURCE #include #include #include #define __USE_MISC #include Later, when is included: #if defined __USE_XOPEN || defined __USE_XOPEN2K8 # define __need_timespec # include # include time.h was included already, and it has guard macros that stop it being included again. Therefore, it doesn't reach the part that would declare timespec. I think the _XOPEN_SOURCE isn't quite right. I think they were trying to get to provide strdup(), but it's not working: > filter-datatypes.c: In function 'fs_resource_value': > filter-datatypes.c:107:16: warning: implicit declaration of function 'strdup' > [-Wimplicit-function-declaration] > res->lex = strdup(v.lex); > ^ > filter-datatypes.c:107:16: warning: incompatible implicit declaration of > built-in function 'strdup' And __USE_MISC to get strptime() and timegm() from , but that's forbidden in feature_test_macros(7): Programs should never define these macros directly: instead, the appropriate feature test macro(s) from the list above should be employed. One solution would be: #define _DEFAULT_SOURCE /* for timegm() */ #define _XOPEN_SOURCE /* for strptime(), strdup() */ but with glibc >= 2.19 it is easier to define _GNU_SOURCE, which implies both of those, and would be consistent with other source files of 4store already doing that. Patch is attached. It eliminates the warning and fixes the build for me on at least kfreebsd-amd64. Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org Subject: use _GNU_SOURCE instead of __USE_MISC From: Steven Chamberlain Date: Sun, 28 Feb 2016 19:39:34 + Defining __USE_MISC directly is forbidden in feature_test_macros(7). Use _GNU_SOURCE, as other source files do already, which implies _XOPEN_SOURCE and __USE_MISC. --- a/src/frontend/filter-datatypes.c +++ b/src/frontend/filter-datatypes.c @@ -18,11 +18,11 @@ * Copyright (C) 2006 Steve Harris for Garlik */ -#define _XOPEN_SOURCE +#define _GNU_SOURCE + #include #include #include -#define __USE_MISC #include #include "filter.h" signature.asc Description: Digital signature
Bug#815712: ilmbase: FPU functions unimplemented on kfreebsd/hurd
tags 815712 + patch
thanks
Hi Mathieu!
Would you like to try my patches (attached) to fix the testsuite on
32-bit x86? Possibly some other 32-bit systems will need to be listed,
although ARM seemed to be unaffected so far.
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
Subject: testBoxAlgo: allow fuzzy match of b12 == b2
From: Steven Chamberlain
Date: Wed, 24 Feb 2016 01:04:11 +
Also fix a pre-existing typo.
--- a/ImathTest/testBoxAlgo.cpp
+++ b/ImathTest/testBoxAlgo.cpp
@@ -886,10 +886,11 @@
assert (approximatelyEqual (b2.min, b4.min, e));
assert (approximatelyEqual (b2.max, b4.max, e));
-assert (approximatelyEqual (b3.max, b4.max, e));
+assert (approximatelyEqual (b3.min, b4.min, e));
assert (approximatelyEqual (b3.max, b4.max, e));
-assert (b21 == b2);
+assert (approximatelyEqual (b2.min, b21.min, e));
+assert (approximatelyEqual (b2.max, b21.max, e));
assert (b31 == b3);
M[0][3] = 1;
Subject: testBox: allow fuzzy comparison of floats, doubles
From: Steven Chamberlain
Date: Wed, 24 Feb 2016 01:10:11 +
Allow for inexact values, as long as the error is smaller than the
epsilon of the data type.
On 32-bit x86, allow even greater discrepency at double
precision, due to possible double-rounding. See
https://lists.nongnu.org/archive/html/openexr-devel/2015-12/msg1.html
--- a/ImathTest/testBox.cpp
+++ b/ImathTest/testBox.cpp
@@ -47,6 +47,58 @@
namespace {
+template
+bool
+approximatelyEqual (const T &p1, const T &p2)
+{
+ /* int and short should be exact */
+ return (p1 == p2);
+}
+
+bool
+approximatelyEqual (const Vec2 &p1, const Vec2 &p2)
+{
+float e = limits::epsilon();
+float m = 0;
+
+for (int i = 0; i < 2; ++i)
+{
+ m = max (m, abs (p1[i]));
+ m = max (m, abs (p2[i]));
+}
+
+for (int i = 0; i < 2; ++i)
+ if (!equalWithAbsError (p1[i], p2[i], m * e))
+ return false;
+
+return true;
+}
+
+bool
+approximatelyEqual (const Vec2 &p1, const Vec2 &p2)
+{
+#if defined(__i386__) || defined(_M_IX86)
+/* double-rounding on 32-bit x86 may cause larger error:
+ use epsilon of float rather than double */
+double e = limits::epsilon();
+#else
+double e = limits::epsilon();
+#endif
+double m = 0;
+
+for (int i = 0; i < 2; ++i)
+{
+ m = max (m, abs (p1[i]));
+ m = max (m, abs (p2[i]));
+}
+
+for (int i = 0; i < 2; ++i)
+ if (!equalWithAbsError (p1[i], p2[i], m * e))
+ return false;
+
+return true;
+}
+
//
// Test case generation utility - create a vector of IMATH_INTERNAL_NAMESPACE::Vec{2,3,4}
// with all permutations of integers 1..T::dimensions().
@@ -250,7 +302,8 @@
IMATH_INTERNAL_NAMESPACE::Box b;
b.extendBy(p);
-assert(b.min == p && b.max == p);
+assert (approximatelyEqual (b.min, p));
+assert (approximatelyEqual (b.max, p));
}
//
@@ -283,7 +336,8 @@
b.extendBy(p);
-assert(b.min == min && b.max == max);
+assert (approximatelyEqual (b.min, min));
+assert (approximatelyEqual (b.max, max));
}
}
}
@@ -358,7 +412,8 @@
}
b.extendBy(IMATH_INTERNAL_NAMESPACE::Box(p0, p1));
-assert(b.min == min && b.max == max);
+assert (approximatelyEqual (b.min, min));
+assert (approximatelyEqual (b.max, max));
}
}
}
signature.asc
Description: Digital signature
Bug#815712: ilmbase: FPU functions unimplemented on kfreebsd/hurd
forwarded 815712 https://lists.nongnu.org/archive/html/openexr-devel/2015-12/msg0.html thanks also: https://lists.gnu.org/archive/html/bug-guix/2015-11/msg00179.html It seems like these large errors are to be expected on most 32-bit arches. Upstream didn't suggest how to fix it, but I'm working on a patch. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#811238: FTBFS: error: ld returned 1 exit status
Martin Michlmayr wrote: > > --- libutil-freebsd.so.9 --- > > building shared library libutil-freebsd.so.9 > > fparseln.So: In function `fparseln': > > /<>/lib/libutil/fparseln.c:115: warning: This functions cannot > > be safely ported, use getline(3) instead, as it is supported by GNU and > > POSIX.1-2008. > > collect2: error: ld returned 1 exit status > > *** [libutil-freebsd.so.9] Error code 1 The package build unfortunately does not show the linker invocation, but here it is: | cc -fstack-protector -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o libutil-freebsd.so.9 -Wl,-soname,libutil-freebsd.so.9 auth.So expand_number.So fparseln.So gr_util.So hexdump.So humanize_number.So login_class.So pidfile.So stub.So trimdomain.So uucplock.So login_cap.So flopen.So _secure_path.So -lbsd -lfreebsd-glue | fparseln.So: In function `fparseln': | lib/libutil/fparseln.c:115: warning: This functions cannot be safely ported, use getline(3) instead, as it is supported by GNU and POSIX.1-2008. | collect2: error: ld returned 1 exit status The warning is fatal due to -Wl,--fatal-warnings, and is coming from libbsd-dev; this should be fairly straightforward to fix. Thanks for the report, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#811280: kfreebsd-10: CVE-2016-1882: TCP MD5 signature denial of service [SA-16:05]
Package: src:kfreebsd-10 Version: 10.1~svn274115-4+kbsd8u1 Severity: grave Tags: security upstream Control: found -1 10.1~svn274115-10 kfreebsd's TCP stack is vulnerable to local (and possibly remote under extreme conditions) denial of service (kernel panic). https://security.FreeBSD.org/advisories/FreeBSD-SA-16:05.tcp.asc This affects kfreebsd-10, and also kfreebsd-9 in wheezy.
Bug#811279: kfreebsd-10: CVE-2016-1881: Linux compatibility layer setgroups(2) system call vulnerability [SA-16:04]
Package: src:kfreebsd-10 Version: 10.1~svn274115-4+kbsd8u1 Severity: grave Tags: security upstream Control: found -1 10.1~svn274115-10 kfreebsd's Linux binary compatibility layer (linux.ko module) may vulnerable to local privilege escalation or denial of service (kernel panic). This module is typically not used by Debian GNU/kFreeBSD unless the system administrator has enabled it. https://security.FreeBSD.org/advisories/FreeBSD-SA-16:04.linux.asc This affects kfreebsd-10, and also kfreebsd-9 in wheezy.
Bug#811278: kfreebsd-10: CVE-2016-1880: Linux compatibility layer incorrect futex handling [SA-16:02]
Package: src:kfreebsd-10 Version: 10.1~svn274115-4+kbsd8u1 Severity: grave Tags: security upstream Control: found -1 10.1~svn274115-10 kfreebsd's Linux binary compatibility layer (linux.ko module) may be vulnerable to local privilege escalation. This module is typically not used by Debian GNU/kFreeBSD unless the system administrator has enabled it. https://security.FreeBSD.org/advisories/FreeBSD-SA-16:03.linux.asc This affects kfreebsd-10, and also kfreebsd-9 in wheezy.
Bug#811277: kfreebsd-10: CVE-2016-1879: SCTP ICMPv6 error message vulnerability [SA-16:01]
Package: src:kfreebsd-10 Version: 10.1~svn274115-4+kbsd8u1 Severity: grave Tags: security upstream Control: found -1 10.1~svn274115-10 Specially crafted SCTP packets via IPv6 can trigger remote denial of service in kfreebsd-10, even if SCTP sockets are not used. https://security.FreeBSD.org/advisories/FreeBSD-SA-16:01.sctp.asc SCTP is disabled in wheezy's latest kfreebsd-9 package, otherwise it would have been affected by this too.
Bug#752650: php-suhosin is licensed under the PHP license and is not PHP
Hi, Reprising this old bug, it's a shame that a good security hardening extension for PHP was kept out of Debian for two releases. I think this turns out to be a different situation than other packages (where things unrelated to PHP code had been put under the PHP license, therefore not being able to satisfy the license terms). On 2014-06-26, Ondřej Surý wrote: | I did have a quite long and extensive chat with FTP Masters | and our conclusion was that PHP License (any version) is | suitable only for software that comes directly from "PHP Group", | that basically means only PHP (src:php5) itself. In the upstream bug[0] it is claimed by the author: "Suhosin incorporates some PHP Code directly" and that they can't relicense Suhosin because of that. But does that mean Suhosin has fully complied with the license? | 1. Redistributions of source code must retain the above copyright | notice, this list of conditions and the following disclaimer. | 2. Redistributions in binary form must reproduce the above copyright | notice, this list of conditions and the following disclaimer in | the documentation and/or other materials provided with the | distribution. Suhosin retains the same license. | 3. The name "PHP" must not be used to endorse or promote products | derived from this software without prior written permission. For | written permission, please contact gr...@php.net. | 4. Products derived from this software may not be called "PHP", nor | may "PHP" appear in their name, without prior written permission | from gr...@php.net. You may indicate that your software works in | conjunction with PHP by saying "Foo for PHP" instead of calling | it "PHP Foo" or "phpfoo" I don't think that was at issue, if the product is called "Suhosin". | 5. The PHP Group may publish revised and/or new versions of the | license from time to time. Each version will be given a | distinguishing version number. | Once covered code has been published under a particular version | of the license, you may always continue to use it under the terms | of that version. You may also choose to use such covered code | under the terms of any subsequent version of the license | published by the PHP Group. No one other than the PHP Group has | the right to modify the terms applicable to covered code created | under this License. Suhosin hasn't modified the license terms. | 6. Redistributions of any form whatsoever must retain the following | acknowledgment: | "This product includes PHP software, freely available from | <http://www.php.net/software/>". The statement is reproduced in the Debian copyright file, and it seems valid, if it really does include PHP software as claimed by upstream. [0]: https://github.com/stefanesser/suhosin/issues/48 Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#754803: healpy: out-of-date binaries
Hi, On kfreebsd-amd64 healpy still FTBFS, but I suspect it just needs a Dep-Wait on python3-matplotlib (>= 1.5.0~)? https://buildd.debian.org/status/fetch.php?pkg=healpy&arch=kfreebsd-amd64&ver=1.8.1-1.1&stamp=1444690648 | __ ERROR collecting .pybuild/pythonX.Y_3.5/build/healpy/test/test_visufunc.py __ | healpy/test/test_visufunc.py:5: in | from ..visufunc import * | healpy/visufunc.py:54: in | from . import projaxes as PA | healpy/projaxes.py:24: in | from matplotlib import axes,ticker,colors,cm,lines,cbook,figure | /usr/lib/python3/dist-packages/matplotlib/axes/__init__.py:4: in | from ._subplots import * | /usr/lib/python3/dist-packages/matplotlib/axes/_subplots.py:7: in | from matplotlib.gridspec import GridSpec, SubplotSpec | /usr/lib/python3/dist-packages/matplotlib/gridspec.py:26: in | import matplotlib.transforms as mtransforms | /usr/lib/python3/dist-packages/matplotlib/transforms.py:39: in | from matplotlib._path import (affine_transform, count_bboxes_overlapping_bbox, | E ImportError: No module named 'matplotlib._path' Newer matplotlib, in turn, is waiting on the glib2.0 FTBFS (https://bugs.debian.org/712848) but that may be fixed in a few days. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#797656: kglobalaccel: out-of-date Build-Depends on (>= 5.12.0~)
Package: kglobalaccel Version: 5.13.0-1 Severity: serious Hi, kglobalaccel/5.13.0-1 FTBFS on a few architectures: kfreebsd-i386, ppc64, and x32 for example: | The following configuration files were considered but not accepted: |/usr/lib/i386-kfreebsd-gnu/cmake/KF5Crash/KF5CrashConfig.cmake, version: 5.12.0 https://buildd.debian.org/status/fetch.php?pkg=kglobalaccel&arch=kfreebsd-i386&ver=5.13.0-1&stamp=1440971005 This is because kglobalaccess had many versioned Build-Depends on (>= 5.12.0~), and these were not bumped when the new upstream version was packaged. At least the libkf5crash-dev package must be (>= 5.13.0~) now; I'm not sure if the other Build-Depends should be (>= 5.13.0~) now also. Thanks! -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
Bug#796996: kfreebsd-10: CVE-2015-5675: IRET privilege escalation
Package: kfreebsd-10 Version: 10.1~svn274115-9 Severity: grave Tags: security upstream patch Hi, Local users can trigger a kernel panic, or possibly escalate privileges, by exploiting a flaw in the IRET handler in kfreebsd-9 and -10: https://www.freebsd.org/security/advisories/FreeBSD-SA-15:21.amd64.asc kfreebsd-8 may also be affected, but that release no longer has security support. kfreebsd-11 was fixed long ago in SVN r275833. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
Bug#787136: kfreebsd-10: crashes seen on KVM-based buildds
Hi, I think porterbox falla has been stable so far. Would it be possible to upgrade an actual buildd sto jessie oon, since at least package nss is waiting for this: https://buildd.debian.org/status/fetch.php?pkg=nss&arch=kfreebsd-amd64&ver=2%3A3.19.2-1&stamp=1434868643 Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#786909: chromium: unconditionally downloads binary blob
Michael Gilbert wrote: > Yes, nacl is intentionally disabled in the Debian packages, [...] > [...] > No, it does not work. Obviously nacl applications cannot execute > without a nacl interpreter. Thanks! That's quite reassuring for Debian users at least. Christoph Anton Mitterer wrote: > I don't think it really matters what upstream claims here, Right, we shouldn't just take their word for it. From what I can tell, the file download was configured by way of a module ID listed as an "import" here: https://sources.debian.net/src/chromium-browser/43.0.2357.124-1/chrome/browser/resources/hotword/manifest.json/#L82 (and didn't exist before Chromium 43, JFTR). (I don't yet understand how the upstream commit stopped the module being downloaded, but rather appears to stop it from being invoked?) https://codereview.chromium.org/1160243004/diff/120001/chrome/browser/search/hotword_service.cc I scanned through the other manifest.json and found one other occurrence which is: https://sources.debian.net/src/chromium-browser/43.0.2357.124-1/ui/file_manager/video_player/manifest.json/?hl=60#L60 Could someone please check if that plugin is enabled? (Seems Mike just committed to packaging Git a way to make hidden extensions visible now). There is some scary code in https://sources.debian.net/src/chromium-browser/43.0.2357.124-1/chrome/browser/chromeos/extensions/file_manager/private_api_misc.cc relating to "https://www.googleapis.com/auth/chromewebstore"; and talking about "silent installation". It relates to Cast API and hopefully is unused in Debian builds (I don't see this file in the Debian package build logs). Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#786909: chromium: unconditionally downloads binary blob
Steven Chamberlain wrote: > would the > DFSG chromium browser be 'more' free if it disabled NaCl? Actually, in the build log I see disable_nacl=1 I'm confused that hotword-x86-64.nexe is "a NaCl module" [0], even though Debian's chromium is built with NaCl 'disabled'? Does this feature actually work at all, even if a user ticks "Enable OK Google" in chrome://settings; is someone able to test that? [0]: https://code.google.com/p/chromium/issues/detail?id=491435#c10 Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#786909: chromium: unconditionally downloads binary blob
Hi, Upstream have said: https://code.google.com/p/chromium/issues/detail?id=491435#c10 > This is not "opt-in default". If you do not explicitly opt in (using > the "Enable Ok Google" setting in chrome://settings), then this module > will not run. That suggests to me that security of users was not put at risk, unless they enabled that optional feature. It was likely 'only' a privacy concern and Debian policy violation. May I ask boldly, is NaCl a legitimate feature of a Debian package in 'main'? I'm reminded of the FSF's John Sullivan speaking at DebConf14 about the DFSG iceweasel browser offering to install non-free software. AIUI NaCl's only purpose is to execute compiled, most likely non-free code? (Whereas minified non-free JavaScript is objectionable to some, this seems an order of magnitude worse). I'm not implying chromium belongs in contrib or non-free - there is already the non-free Chrome as an option there - but rather, would the DFSG chromium browser be 'more' free if it disabled NaCl? I also propose more QA within Debian to find applications phoning home, which could have been detected in this case within something like the autopkgtest framework and simply opening a page on a local webserver. Sorry, if you feel this is off-topic for the bug log, please take it to an appropriate list but preferably keep me in Cc: if you do. Christoph Anton Mitterer wrote: > And there's still no single sign of properly visible announcements to > user what might have happened here. :( The bug made it to Hacker News, so that has been accomplished now to some extent. Thanks Chris for speaking up about this. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#787136: kfreebsd-10: crashes seen on KVM-based buildds
Paul Wise wrote: > On Sun, 14 Jun 2015 15:07:01 +0100 Steven Chamberlain wrote: > > I think we should rather be using if=virtio now anyway. Could we try > > to switch falla to that, and hopefully the issue might go away? > > Switched to that: > > gnt-instance shutdown falla.debian.org > gnt-instance modify -d -H disk_type=paravirtual falla.debian.org > gnt-instance shutdown falla.debian.org Thanks! > > I suggest we may rather want to use diskids in /etc/fstab > > Could you outline how that works on kFreeBSD? Looking on falla, I actually don't see any /dev/diskid/ entries listed in /proc/partitions, so I guess this is not possible right now; not sure why. > Should we make that the default in stretch and or jessie? It's something we should implement in debian-installer for sid/stretch. Similar to the UUID entries used on Linux for many years now. > > And while here, I recommend enabling soft updates journalling > > It asked me to run fsck but doing that didn't help. > > fsck -y /dev/vtbd1s1 > tunefs.ufs -j enable /dev/vtbd1s1 > tunefs.ufs: soft updates journaling cannot be enabled until fsck is run > tunefs.ufs: /dev/vtbd1s1: failed to write superblock Odd error message. Was it unmounted? (not just mounted read-only) I would also have tried to call fsck.ufs directly for good measure. If you do have the chance to try it again, it may be useful to install ktrace first and use that to get a system call trace (ktrace.out) to analyse later, e.g.: # ktrace -di -- tunefs.ufs -j enable /dev/vtbd1s1 I can meanwhile try to find a way to reproduce it myself. > > And set up as much logging as possible to the serial console (boot > > with kernel flags -D -h, /etc/grub.d/10_kfreebsd), in case Ganeti can > > keep logs of that, as it should help for issues like this. > > -D was in there already, added -h, now this command works: > gnt-instance console falla.debian.org > > Should we make that the default in stretch and jessie? For jessie, when /etc/default/grub has GRUB_TERMINAL="serial console", I'd like those flags to be set automatically by /etc/grub.d/10_kfreebsd. When I've finished that, we could replace falla's modified /etc/grub.d/10_kfreebsd with a pristine copy. Thanks again, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#787136: kfreebsd-10: crashes seen on KVM-based buildds
Julien Cristau wrote: > On Sun, Jun 14, 2015 at 15:07:01 +0100, Steven Chamberlain wrote: > > I'm just curious what qemu-kvm version is used on falla's KVM host? > > As 1.1.2+dfsg-6+deb7u8 in wheezy had some issues. > > > It's 1:2.1+dfsg-12+deb8u1. Thanks. That is the version I've been testing with. I couldn't reproduce the if=ide problem as seen on the buildds, but if=virtio has been stable too. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#787136: kfreebsd-10: crashes seen on KVM-based buildds
Paul Wise wrote: > Nothing in kern.log as I don't think it could write to the disk (if=ide) > when it was having issues before. I couldn't reproduce this yet in a KVM test environment with if=ide, having run lots of package builds, a 'make universe' of all FreeBSD and some other disk benchmarks to try to stress it. I'm just curious what qemu-kvm version is used on falla's KVM host? As 1.1.2+dfsg-6+deb7u8 in wheezy had some issues. I think we should rather be using if=virtio now anyway. Could we try to switch falla to that, and hopefully the issue might go away? The procedure for that is outlined at https://bugs.debian.org/787136#20 though I suggest we may rather want to use diskids in /etc/fstab, making it easy to switch back if needed. And while here, I recommend enabling soft updates journalling, on any UFS partition except / and /boot, as we do for new installs now. It can only be changed while partitions are unmounted, with: # tunefs.ufs -j enable /dev/foo And set up as much logging as possible to the serial console (boot with kernel flags -D -h, /etc/grub.d/10_kfreebsd), in case Ganeti can keep logs of that, as it should help for issues like this. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#787136: kfreebsd-10: crashes seen on KVM-based buildds
Steven Chamberlain wrote: > Paul Wise wrote: > > The VM console looks like this afterwards: > > https://people.debian.org/~pabs/tmp/falla.png > > Very helpful, thanks. It's a disk I/O problem (with emulated IDE > disks); vfs is unable to flush I/O to ada0s1. I think falla crashed again in the same way sometime in the past hour. Is serial console output logged anywhere by Ganeti? Are there any other kernel messages prior to the first g_vfs_done() error? (The monit errors in your screenshot may have pushed other details off-screen; and (No log file within the VM would have it as the bug seems to affect disk I/O to all partitions; the monitor errors in your screenshot may have pushed other details off-screen, although ScrollLck-PageUp might work). Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#787136: kfreebsd-10: crashes seen on KVM-based buildds
Christoph Egger wrote: > This actually sounds a lot like what I just had on my VM! It also has > stuff along the following lines in /var/log/kern.log: > > | May 31 04:41:06 localhost kernel: maxproc limit exceeded by uid 101 (pid > 1685); see tuning(7) and login.conf(5) That doesn't look related to the kernel messages pabs showed (though the effect on sshd is the same). I have seen it long ago with kfreebsd-9: https://bugs.debian.org/705126 Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#787136: kfreebsd-10: crashes seen on KVM-based buildds
Paul Wise wrote: > The VM console looks like this afterwards: > https://people.debian.org/~pabs/tmp/falla.png Very helpful, thanks. It's a disk I/O problem (with emulated IDE disks); vfs is unable to flush I/O to ada0s1. sshd is failing because it can no longer read from swap space (vm_fault) and that also suggests there was memory pressure that maybe contributed to this bug occurring. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#787136: kfreebsd-10: crashes seen on KVM-based buildds
Also if either virtio-net is used, or booting from virtio-blk, Qemu 1.1.2+dfsg-6a+deb7u7 triggers a panic in atkbd driver on boot; Qemu 1:2.1+dfsg-12~bpo70+1 has fixed that however. I've completed test builds of glibc with ide and virtio-blk, which oddly showed no difference in build time. No stability issue or odd kernel messages seen so far. I'll keep this test system busy with package builds and other tasks, but could use more hints on what might trigger the issue seen with falla.debian.org. (And exactly what issue was seen there, a crash? with or without automatic reboot?). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787136: kfreebsd-10: crashes seen on KVM-based buildds
Christoph Egger wrote: > I have a kfreebsd that boots via virtio. And I'm pretty sute it was > created with virtio disks. I'll check once home again. I already found out the following today: grub-probe doesn't know about /dev/vtbd* disks, so it can't install boot blocks to a new virtio disk without a patch (I'll upload this to jessie-kfreebsd-p-u soon). If the boot blocks are already there, GRUB2 can boot such a disk, and kfreebsd-10 supports it too. (kfreebsd-9 didn't IIRC) It is possible to migrate from if=ide to if=virtio by altering /etc/fstab (/dev/ada -> /dev/vtbd), and the root device in /boot/grub/grub.cfg, before making that change. If you forget to make those changes in advance, it is still possible (but somewhat awkward) to rescue it and make those changes via VNC. Likewise one can migrate e1000 to virtio-net by changing /etc/network/interfaces (em0 -> vtnet0). I think we ought to do this anyway for the buildds and porterboxes? Furthermore it may avoid the stability issue (if that was related to the emulated IDE disk or e1000 NIC). Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#787136: kfreebsd-10: crashes seen on KVM-based buildds
Hi, I've set up a clone of the buildds' KVM setup (without Ganeti), and with emulated IDE disks this is *crazy* slow. Do Linux buildd VMs also use if=ide, or is only kfreebsd using that? (Would make sense because, I don't think if=scsi is bootable, and if=virtio wasn't supported before kfreebsd-10; grub2 still needs a patch to install to the latter as a boot disk). Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787136: kfreebsd-10: crashes seen on KVM-based buildds
Package: src:kfreebsd-10 Version: 10.1~svn274115-4 Severity: grave Tags: moreinfo X-Debbugs-Cc: debian-adm...@lists.debian.org Hi, Christoph Egger wrote: > Peter from DSA upgraded the porterbox, falla, and experienced huge > stability problems I could not reproduce [...] I tested kfreebsd-10 quite heavily on KVM and did not see anything like this. Please tell me what the Debian buildd setup looks like; what kind of virtual network and disk devices are used? Output of dmesg may be able to fully answer that. Also, please describe the crash. Does it reboot automatically, hang, or something else? Does it still respond to pings, does sshd still respond, etc. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#785491: xserver-xorg-video-siliconmotion FTBFS on arm64, implicit declarations of inb and outb
peter green wrote: > In file included from ../../src/smi.h:317:0, > from ../../src/smi_501.c:33: > ../../src/regsmi.h: In function 'VGAIN8_INDEX': > ../../src/regsmi.h:67:2: error: implicit declaration of function 'outb' > [-Werror=implicit-function-declaration] > outb(pSmi->PIOBase + indexPort, index); > ^ I don't think any change in xserver-xorg-video-siliconmotion caused this. Please could you compare output of: $ gcc -I/usr/include/pixman-1 -E xorg-server-1.16.4/hw/xfree86/common/compiler.h > a.txt $ gcc -I/usr/include/pixman-1 -E xorg-server-1.17.1/hw/xfree86/common/compiler.h > b.txt on AArch64, with the sources from jessie and sid: http://httpredir.debian.org/debian/pool/main/x/xorg-server/xorg-server_1.16.4-1.dsc http://httpredir.debian.org/debian/pool/main/x/xorg-server/xorg-server_1.17.1-2.dsc There were changes in that header for arch-specific handling of outb() and friends. This could be a regression; or possibly wrong definitions were used before (allowing it to build when it should not have). Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#779201: kfreebsd-{8,9}: CVE-2015-1414: DoS via IGMP packet
Dear Security Team,
This bug was reopened because the original fix from upstream was found
to be incomplete.
Please may I upload to wheezy-security with the attached debdiff,
replacing the CVE-2015-1414 patch with the new one, and also patching
CVE-2015-2923 (Debian Bug #782735).
I've been running kfreebsd-9 with these patches for some weeks, and
they are applied already to kfreebsd-10 in sid/jessie-kfreebsd.
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
diff -Nru kfreebsd-9-9.0/debian/changelog kfreebsd-9-9.0/debian/changelog
--- kfreebsd-9-9.0/debian/changelog 2015-02-25 13:13:10.0 +
+++ kfreebsd-9-9.0/debian/changelog 2015-05-10 19:53:49.0 +
@@ -1,3 +1,13 @@
+kfreebsd-9 (9.0-10+deb70.10) wheezy-security; urgency=high
+
+ * Pick SVN r281231 from FreeBSD 9-STABLE to fix:
+- SA-15:04: integer overflow in IGMP protocol (CVE-2015-1414)
+ updated patch from advisory revision 1.1 (Closes: #779201)
+- SA-15:09: Denial of Service with IPv6 Router Advertisements
+ (CVE-2015-2923) (Closes: #782735)
+
+ -- Steven Chamberlain Thu, 16 Apr 2015 21:45:05 +
+
kfreebsd-9 (9.0-10+deb70.9) wheezy-security; urgency=medium
* Upstream patch for FreeBSD-SA-15:04.igmp / CVE-2015-1414 (Closes: #779201)
diff -Nru kfreebsd-9-9.0/debian/patches/SA-15_04.igmp.patch
kfreebsd-9-9.0/debian/patches/SA-15_04.igmp.patch
--- kfreebsd-9-9.0/debian/patches/SA-15_04.igmp.patch 1970-01-01
00:00:00.0 +
+++ kfreebsd-9-9.0/debian/patches/SA-15_04.igmp.patch 2015-04-16
21:44:56.0 +
@@ -0,0 +1,41 @@
+Description:
+ Fix integer overflow in IGMP protocol [SA-15:04] (CVE-2015-1414)
+ .
+ Updated patch from advisory revision 1.1
+Origin: vendor, https://security.FreeBSD.org/patches/SA-15:04/igmp-errata.patch
+Bug: https://www.freebsd.org/security/advisories/FreeBSD-SA-15:04.igmp.asc
+Bug-Debian: https://bugs.debian.org/779201
+Applied-Upstream: https://svnweb.freebsd.org/base?view=revision&revision=281231
+
+--- a/sys/netinet/igmp.c
b/sys/netinet/igmp.c
+@@ -1532,8 +1532,7 @@
+ case IGMP_VERSION_3: {
+ struct igmpv3 *igmpv3;
+ uint16_t igmpv3len;
+- uint16_t srclen;
+- int nsrc;
++ uint16_t nsrc;
+
+ IGMPSTAT_INC(igps_rcv_v3_queries);
+ igmpv3 = (struct igmpv3 *)igmp;
+@@ -1541,8 +1540,8 @@
+* Validate length based on source count.
+*/
+ nsrc = ntohs(igmpv3->igmp_numsrc);
+- srclen = sizeof(struct in_addr) * nsrc;
+- if (nsrc * sizeof(in_addr_t) > srclen) {
++ if (nsrc * sizeof(in_addr_t) >
++ UINT16_MAX - iphlen - IGMP_V3_QUERY_MINLEN)
{
+ IGMPSTAT_INC(igps_rcv_tooshort);
+ return;
+ }
+@@ -1551,7 +1550,7 @@
+* this scope.
+*/
+ igmpv3len = iphlen + IGMP_V3_QUERY_MINLEN +
+- srclen;
++ sizeof(struct in_addr) * nsrc;
+ if ((m->m_flags & M_EXT ||
+m->m_len < igmpv3len) &&
+ (m = m_pullup(m, igmpv3len)) == NULL) {
diff -Nru kfreebsd-9-9.0/debian/patches/SA-15_09.ipv6.patch
kfreebsd-9-9.0/debian/patches/SA-15_09.ipv6.patch
--- kfreebsd-9-9.0/debian/patches/SA-15_09.ipv6.patch 1970-01-01
00:00:00.0 +
+++ kfreebsd-9-9.0/debian/patches/SA-15_09.ipv6.patch 2015-04-16
21:36:56.0 +
@@ -0,0 +1,28 @@
+Description:
+ Fix Denial of Service with IPv6 Router Advertisements [SA-15:09]
(CVE-2015-2923)
+Origin: vendor, https://security.FreeBSD.org/patches/SA-15:09/ipv6.patch
+Bug: https://www.freebsd.org/security/advisories/FreeBSD-SA-15:09.ipv6.asc
+Bug-Debian: https://bugs.debian.org/782735
+Applied-Upstream: https://svnweb.freebsd.org/base?view=revision&revision=281231
+
+--- a/sys/netinet6/nd6_rtr.c
b/sys/netinet6/nd6_rtr.c
+@@ -293,8 +293,16 @@
+ }
+ if (nd_ra->nd_ra_retransmit)
+ ndi->retrans = ntohl(nd_ra->nd_ra_retransmit);
+- if (nd_ra->nd_ra_curhoplimit)
+- ndi->chlim = nd_ra->nd_ra_curhoplimit;
++ if (nd_ra->nd_ra_curhoplimit) {
++ if (ndi->chlim < nd_ra->nd_ra_curhoplimit)
++ ndi->chlim = nd_ra->nd_ra_curhoplimit;
++ else if (ndi->chlim != nd_ra->nd_ra_curhoplimit) {
++ log(LOG_ERR, "RA with a lower
Bug#783205: clang-3.5: fatal error: 'sys/cdefs.h' file not found
tags 783205 + patch
thanks
Hi Sylvestre,
As well as C header include path, there were also issues finding
standard libraries and the dynamic linker on s390x. (Exactly the
same issues as we had on kfreebsd a few months back.)
I've written the attached patch for s390x, tested on Debian's s390x
porterbox, which successfully compiles a small C or C++ executable now.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
From: Steven Chamberlain
Date: Sun, 10 May 2015 19:46:59 +0100
Subject: support Debian s390x multiarch paths
--- a/clang/lib/Driver/ToolChains.cpp
+++ b/clang/lib/Driver/ToolChains.cpp
@@ -2990,6 +2990,10 @@ static std::string getMultiarchTriple(co
if (llvm::sys::fs::exists(SysRoot + "/lib/powerpc64le-linux-gnu"))
return "powerpc64le-linux-gnu";
return TargetTriple.str();
+ case llvm::Triple::systemz:
+if (llvm::sys::fs::exists(SysRoot + "/lib/s390x-linux-gnu"))
+ return "s390x-linux-gnu";
+return TargetTriple.str();
}
}
@@ -3361,6 +3365,9 @@ void Linux::AddClangSystemIncludeArgs(co
const StringRef PPC64LEMultiarchIncludeDirs[] = {
"/usr/include/powerpc64le-linux-gnu"
};
+ const StringRef SYSTEMZMultiarchIncludeDirs[] = {
+"/usr/include/s390x-linux-gnu"
+ };
ArrayRef MultiarchIncludeDirs;
if (getTriple().getArch() == llvm::Triple::x86_64) {
MultiarchIncludeDirs = X86_64MultiarchIncludeDirs;
@@ -3390,6 +3397,8 @@ void Linux::AddClangSystemIncludeArgs(co
MultiarchIncludeDirs = PPC64MultiarchIncludeDirs;
} else if (getTriple().getArch() == llvm::Triple::ppc64le) {
MultiarchIncludeDirs = PPC64LEMultiarchIncludeDirs;
+ } else if (getTriple().getArch() == llvm::Triple::systemz) {
+MultiarchIncludeDirs = SYSTEMZMultiarchIncludeDirs;
}
for (StringRef Dir : MultiarchIncludeDirs) {
if (llvm::sys::fs::exists(SysRoot + Dir)) {
--- a/clang/lib/Driver/Tools.cpp
+++ b/clang/lib/Driver/Tools.cpp
@@ -7223,13 +7223,14 @@ static StringRef getLinuxDynamicLinker(c
? "/lib64/ld-linux-mipsn8.so.1" : "/lib64/ld.so.1";
} else if (ToolChain.getArch() == llvm::Triple::ppc)
return "/lib/ld.so.1";
- else if (ToolChain.getArch() == llvm::Triple::ppc64 ||
- ToolChain.getArch() == llvm::Triple::systemz)
+ else if (ToolChain.getArch() == llvm::Triple::ppc64)
return "/lib64/ld64.so.1";
else if (ToolChain.getArch() == llvm::Triple::ppc64le)
return "/lib64/ld64.so.2";
else if (ToolChain.getArch() == llvm::Triple::sparcv9)
return "/lib64/ld-linux.so.2";
+ else if (ToolChain.getArch() == llvm::Triple::systemz)
+return "/lib/ld64.so.1";
else if (ToolChain.getArch() == llvm::Triple::x86_64 &&
ToolChain.getTriple().getEnvironment() == llvm::Triple::GNUX32)
return "/libx32/ld-linux-x32.so.2";
signature.asc
Description: Digital signature
Bug#782976: debian-installer-netboot-images packages kfreebsd images but kfreebsd is not in jessie.
Hi peter, I think it's been removed today already: https://packages.qa.debian.org/d/debian-installer-netboot-images/news/20150423T215008Z.html Do you agree? And this bug can be closed. > It could presumablly be > modified to look in an unofficial location Yeah, I guess we'll have a jessie-kfreebsd suite, where we patch this package to do exactly that. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#783205: s390x porterbox access (was: Bug#783205: clang-3.5: fatal error: 'sys/cdefs.h' file not found)
Hi, Please could I get access to a s390x porterbox, and I will take a look at this bug. My Alioth account is stevenc-guest, and I have accepted the DMUP: https://lists.debian.org/debian-newmaint/2015/01/msg1.html Sylvestre Ledru wrote: > I am quite busy these days. I won't have the time to look at it > before a few weeks. > > We probably have to update this code: > http://sources.debian.net/src/llvm-toolchain-3.5/1:3.5-10/clang/lib/Driver/ToolChains.cpp/#L1396 s390x-linux-gnu triplet looks correct there. I think more likely s390x is missing knowledge of Debian-style multiarch paths in this later section: https://sources.debian.net/src/llvm-toolchain-3.5/1:3.5-10/clang/lib/Driver/ToolChains.cpp/#L2899 Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#779195: kfreebsd-10: CVE-2015-1414: DoS via IGMP packet
found 779195 kfreebsd-10/10.1~svn274115-3 notfixed 779195 kfreebsd-10/10.1~svn274115-3 thanks A new version of the patch was issued in revision 1.1 of the advisory. It seems the original patch did not entirely fix the bug. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#782107: kfreebsd-10: CVE-2015-2923: IPv6 Hop limit lowering via RA messages
Package: src:kfreebsd-10 Version: 10.1~svn274115-3 Severity: grave Tags: security Hi, A local-network DoS was reported in the IPv6 stack of FreeBSD: https://www.freebsd.org/security/advisories/FreeBSD-SA-15:09.ipv6.asc (the same issue as CVE-2015-2922 on Linux). This affects all our kfreebsd-8, -9, -10 and -11 packages. Debian GNU/kFreeBSD packages enable "accept_rtadv" by default, so are vulnerable to this DoS unless that flag is manually disabled on an interface, or IPv6 connectivity not used. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776676: grub-efi-amd64: grub-probe, update-grub on Debian Jessie cannot detect zfs filesystem running with the latest code
severity 776676 important # (ZFS isn't part of the official install images yet) thanks Hi, Azeem Esmail wrote: > This issue may be linked to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775395 Yes, exactly. grub-probe fails because of incompatible zpool features that are enabled by default. The error message is not very helpful and could be improved. Instead of creating a zpool like this: > zpool create -m none spool mirror /dev/sde /dev/sdf You must use the -d option. You can still enable LZ4 because GRUB 2.02 has support for it: > zpool create -d -o feature@lz4_compress=enabled -m none spool mirror /dev/sde > /dev/sdf Where did you find these daily installer builds with ZFS support? And what instructions did you follow? (The documentation should be updated with the information above). I'll be committing a fix for #775395 in partman-zfs soon. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#779195: kfreebsd-10: CVE-2015-1414: DoS via IGMP packet
Package: src:kfreebsd-10 Version: 10.1~svn274115-2 Severity: grave Tags: security upstream patch Hi, A remote DoS was reported in FreeBSD's IGMP packet handling: https://www.freebsd.org/security/advisories/FreeBSD-SA-15:04.igmp.asc This affects all our kfreebsd-8, -9, -10 and -11 packages. I don't know yet if this can be exploited over the public Internet or only on a local network segment. As a mitigation, the PF firewall can probably be configured to block 'proto igmp' packets before the kernel processes them. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#779194: kfreebsd-10: CVE-2014-0998: vt crash via ioctl
Package: src:kfreebsd-10 Version: 10.1~svn274115-2 Severity: grave Tags: security upstream patch Control: found -1 kfreebsd-10/10.0-3 Hi, An unprivileged local user can trigger an out-of-bounds memory access in the kernel via an ioctl to vt(4) (aka. newcons). https://security.FreeBSD.org/patches/EN-15:01/vt.patch Upstream's advisory only describes potential impact as a kernel panic. The original researcher's advisory mentioned privilege escalation, but it's ambiguous if that referred to this bug, and unclear if it could be exploitable for that. Debian GNU/kFreeBSD introduced newcons into 10.0-3 as a backport. kfreebsd-10 in jessie/sid enables it by default. So does kfreebsd-11 in experimental. kfreebsd-8 and -9 in wheezy are unaffected as they do not have newcons. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775395: partman-zfs in d-i jessie image does not create grub-compatible /boot ZFS mirror
Control: severity -1 important Michael Milligan wrote: > Package: partman-zfs > Version: 42 > Severity: grave > Tags: d-i > Justification: renders package unusable for ZFS-based install > > (which is probably the reason someone is trying Debian/kFreeBSD .. to > use ZFS) Since this is a kfreebsd-any package, and we're not part of the official stable release, I have to lower this to non-RC severity. We should still fix it for the GNU/kFreeBSD release though. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775395: partman-zfs in d-i jessie image does not create grub-compatible /boot ZFS mirror
Hi, Michael Milligan wrote: > But installing Grub failed with "unknown filesystem". In > troubleshooting the issue, it seems grub2 (version currently is > 2.02~beta2-19) does not recognize the "feature@lz4_compress" option (and > had been previously reported) of the ZFS pools that kFreeBSD kernel 10.1 > creates. Thanks for the report. It is actually expected that grub2 since 2.02 should understand these feature flags, including LZ4 compression. I thought it was working for me when I last tested. Hopefully this can be figured out without having to default to using "-d" (disabling new features including LZ4 metadata compression). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776416: kfreebsd-10: CVE-2014-8613: SCTP stream reset vulnerability
Package: kfreebsd-10 Version: 10.1~svn274115-1 Severity: grave Tags: security patch Hi, A unprivileged local DoS was reported in the FreeBSD kernel implementation of SCTP: https://security.freebsd.org/advisories/FreeBSD-SA-15:03.sctp.asc This only affects systems serving SCTP connections. A patch from upstream should be uploaded soon fixing this in kfreebsd-10. kfreebsd-9 in stable is not affected, since the last security upload 9.0-10+deb70.8 disabled this protocol. kfreebsd-8 does not receive regular security updates, but we may decide to disable SCTP there too. (It's expected nobody would be using SCTP in GNU/kFreeBSD squeeze or prior, because no userland tools had been ported yet). -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776415: kfreebsd-10: CVE-2014-8612: SCTP kernel mem disclosure/corruption
Package: kfreebsd-10 Version: 10.1~svn274115-1 Severity: grave Tags: security patch Hi, A kernel memory disclosure/corruption vulnerability was announced, in the FreeBSD kernel's implementation of SCTP: https://security.FreeBSD.org/advisories/FreeBSD-SA-15:02.kmem.asc This could affect the kfreebsd-10 package if SCTP is used. A patch from upstream should be uploaded soon fixing this. kfreebsd-9 in stable is not affected, since the last security upload 9.0-10+deb70.8 already disabled this protocol. kfreebsd-8 does not receive regular security updates, but we may decide to disable SCTP there too. kfreebsd-11 experimental will be affected until updated to a newer snapshot. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739828: enigmail: mistaken identity of signature
# tentatively lowering severity, but I still think it's a security risk severity 739828 important tags 739828 + security # the referenced upstream bug seems unrelated to this? notforwarded 739828 notfixed 739828 enigmail/2:1.6-1 # issue is still there found 739828 2:1.7.2-1~deb7u1 thanks Hi, Sorry for leaving this bug unanswered so long. I don't much use enigmail/icedove any more. But I checked today with the latest enigmail in wheezy that this issue is still present. I notice something new I didn't realise before. One of the attachments in the mail (ForwardedMessage.eml) *was* signed by me (in the detached signature.asc, also attached), and that's the signature really being verified here. The attach screenshot illustrates this. The problem is that the first/main part of the message (see https://lists.debian.org/debian-bsd/2014/02/msg00244.html) is not signed at all. Anything could be written there, the headers could be forged, and the user interface would still show green / "Good signature from <...>". (The timestamp of the signature at the top, and list of attachments at the bottom are not expanded/shown by default). An imposter would simply attach an old, legitimately signed mail from the sender to be spoofed, and enigmail would make the whole mail appear to be genuine. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#772659: kfreebsd-8: build-depends on gcc-4.6
Hi, Christoph Egger wrote: > Cyril Brulebois writes: > > kfreebsd-9 went away during the transition to kfreebsd-10, and I guess > > kfreebsd-8 was overlooked/forgotten about because it wasn't being > > transitioned from. Should probably go away from the archive entirely? > > I don't see it around actually > > christoph@coccia % dak ls kfreebsd-8 > kfreebsd-8 | 8.1+dfsg-8+squeeze4 | oldstable | source > kfreebsd-8 | 8.2-15~bpo60+1 | squeeze-backports | source > kfreebsd-8 | 8.3-6+deb7u1| stable| source It's still referenced by the debian-installer-netboot-images built using that kernel; it will go away once that package is updated for jessie: | Package: debian-installer-7.0-netboot-kfreebsd-amd64 | Source: debian-installer-netboot-images | Version: 20130613+deb7u2.b3 | Built-Using: [...], kfreebsd-8 (= 8.3-6+deb7u1), kfreebsd-9 (= 9.0-10+deb70.7) Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771387: siliconmotion graphic card driver segfault and unusable.
reassign 771387 xserver-xorg-video-siliconmotion found 771387 1:1.7.7-2+b2 forcemerge 594684 771387 thanks Hello, lumin wrote: > The xserver-xorg-video-siliconmotion segfaults right away once I started > X, and then the X is totally unuseable on my machine (mipsel, > loongson-2f). This is https://bugs.debian.org/594684 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#768140: torsocks: FTBFS on kfreebsd-*
Steven Chamberlain wrote:
> For FreeBSD I came up with the attached, hackish workaround
> using SO_TYPE (widely available), and out of the available
> protocols in PF_LOCAL (= AF_UNIX), assume that only
> SOCK_{DGRAM,SEQPACKET,STREAM} are candidates for fd passing.
Actually it didn't work:
| $ ./test_fd_passing
| 1..5
| ok 1 - Inet socket 3 created connected to 93.95.227.222
| ok 2 - Unix socket 4 created at /tmp/torsocks-unix-fd-passing.sock
| ok 3 - Inet socket 3 sent successfully.
| ok 4 - Data received successfully
| not ok 5 - Received INET socket through the unix socket
| # Failed test (test_fd_passing.c:thread_recv() at line 374)
| # Looks like you failed 1 test of 5.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#768140: torsocks: FTBFS on kfreebsd-*
intrig...@debian.org wrote:
> The fix for #766306 makes torsocks FTBFS on kfreebsd-*:
> https://buildd.debian.org/status/package.php?p=torsocks
Hi,
SO_DOMAIN was only accepted into POSIX earlier this year:
http://austingroupbugs.net/view.php?id=840
it seems to be only available yet on Linux and Solaris.
For FreeBSD I came up with the attached, hackish workaround
using SO_TYPE (widely available), and out of the available
protocols in PF_LOCAL (= AF_UNIX), assume that only
SOCK_{DGRAM,SEQPACKET,STREAM} are candidates for fd passing.
Perhaps someone has a better idea?
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- a/src/lib/recv.c
+++ b/src/lib/recv.c
@@ -60,7 +60,11 @@
*/
LIBC_RECVMSG_RET_TYPE tsocks_recvmsg(LIBC_RECVMSG_SIG)
{
+#ifdef SO_DOMAIN
int sock_domain;
+#else
+ int sock_type;
+#endif
socklen_t optlen;
ssize_t ret = 0;
char dummy, recv_fd[CMSG_SPACE(SCM_MAX_FD)];
@@ -68,6 +72,7 @@
struct cmsghdr *cmsg;
struct msghdr msg_hdr;
+#ifdef SO_DOMAIN
/* Don't bother if the socket family is NOT Unix. */
optlen = sizeof(sock_domain);
ret = getsockopt(sockfd, SOL_SOCKET, SO_DOMAIN, &sock_domain, &optlen);
@@ -79,6 +84,21 @@
if (sock_domain != AF_UNIX) {
goto libc;
}
+#else
+ /* Don't bother if the socket type unsuitable for fd passing */
+ optlen = sizeof(sock_type);
+ ret = getsockopt(sockfd, SOL_SOCKET, SO_TYPE, &sock_type, &optlen);
+ if (ret < 0) {
+ DBG("[recvmsg] Fail getsockopt() on sock %d", sockfd);
+ errno = EBADF;
+ goto error;
+ }
+ if (sock_type != SOCK_DGRAM &&
+ sock_type != SOCK_SEQPACKET &&
+ sock_type != SOCK_STREAM) {
+ goto libc;
+ }
+#endif
memset(&msg_hdr, 0, sizeof(msg_hdr));
Bug#768379: krb5-1.12.1+dfsg-12 FTBFS on kfreebsd
Benjamin Kaduk wrote: > This change in the system headers causes krb5 to FTBFS on kfreebsd > systems. Luckily, upstream krb5 (me) has already fixed this in git commit > 37f87c189ff050c01282f3d8da7bc97fe8a9ea92, so we just need to cherry-pick > that patch. Oh, thanks for noticing! And fixing so quickly. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#768104: kfreebsd-9: CVE-2014-8476: getlogin kernel memory disclosure
Package: src:kfreebsd-9 Version: 9.0-10+deb70.7 Severity: grave Tags: security patch upstream Hi, kfreebsd 9.0 (not officially supported upstream) seems vulnerable to an issue just announced in 9.1 and later: http://security.FreeBSD.org/advisories/FreeBSD-SA-14:25.setlogin.asc kfreebsd-8 8.3 in wheezy, kfreebsd-10 in sid/jessie, and kfreebsd-11 in experimental also seem to be affected by this. -- System Information: Debian Release: jessie/sid Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766250: eject: [kfreebsd] fails to open cdrom tray
tags 766250 + wheezy thanks Hi, There seems to be no problem with this on a jessie system. I'm still leaving this 'gift' bug if someone would like practice at simple debugging on kfreebsd. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766849: gnome-shell responds and renders hazardously
Hello, Perhaps you could share more details of your system; it sounds like maybe a graphics driver problem. Maybe you only see issues under GNOME because 3D acceleration is active all of the time. You can probably gather the most relevant info by running: $ /usr/share/bug/xserver-xorg/script 3>&1 You may want to pipe that through `gzip --best` and attach it to this bug report. Thanks. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767583: ar9300_devid.h license restricts modification
forwarded 767583 freebsd-driv...@lists.freebsd.org thanks -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767583: kfreebsd-10: ar9300_devid.h license restricts modification
Hi, Christoph Egger wrote: > Riley writes: > > After reading a discussion on the gnu-linux-libre mailing list [1], > > I found that the two files named ar9300_devid.h have a license that > > restricts modification: > What does linux do (doesn't seem obvious from the link you > quoted but codesearch seems to indicate debian linunx doesn't have it)? Linux has a useful 3-clause BSD file: http://sources.debian.net/src/linux/3.16.5-1/drivers/net/wireless/ath/ath9k/reg.h/ If we stripped that file of everything except the AR_SREV_REVISION_9* and AR_SREV_VERSION_9* macros, prefixed the chipset numbers with the abbreviated name of the manufacturer (AR or QCA), I think we'd have all that's needed to still compile the FreeBSD driver. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767287: trafficserver: ftbfs on kfreebsd
tags 767287 + patch thanks Hi, Arno Töll wrote: > On 30.10.2014 00:10, Steven Chamberlain wrote: > > I guess the .install file may have some kind syntax to mark that file > > [linux-any]? > > Sadly not. However, we may find another way to get it build on kfreebsd. Then how about the attached? Works for me, at least. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org --- debian/rules.orig 2014-08-10 12:04:08.0 +0100 +++ debian/rules 2014-10-31 00:54:18.602110978 + @@ -32,6 +32,11 @@ rm -f debian/tmp/usr/lib/trafficserver/lib*.la rm -f debian/tmp/usr/lib/trafficserver/modules/*.la rm -f debian/tmp/usr/lib/trafficserver/lib*.a +ifneq ($(DEB_HOST_ARCH_OS),linux) + # Remove Linux-specific plugin + sed -i '/\/healthchecks\.so$$/d' \ + debian/trafficserver-experimental-plugins.install +endif override_dh_install: dh_install --list-missing
Bug#767287: trafficserver: ftbfs on kfreebsd
On 29/10/14 21:04, Ivo De Decker wrote: > The latest upload of trafficserver ftbfs on kfreebsd, where it build fine > before. This prevents migration to testing. Hi, The build appears to be successful. But the trafficserver-experimental-plugins package, added by: http://anonscm.debian.org/cgit/collab-maint/trafficserver.git/commit/?id=4e506a9770cb06c5178921f482427b9d28958dae lists a healthchecks.so, which is not built on kfreebsd. That module requires Linux headers: http://sources.debian.net/src/trafficserver/5.1.0-1/plugins/experimental/healthchecks/healthchecks.c/#L31 | /* ToDo: Linux specific */ | #include | #include I guess the .install file may have some kind syntax to mark that file [linux-any]? Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#767051: libjinput-java: uninstallable on kfreebsd
Hi, On 28/10/14 03:16, Michael Gilbert wrote: > This package currently depends on libjinput-jni, which is currently > not build on the kfreebsds (#657771), so the libjinput-java is > uninstallable on those architectures. Not a bug? libjinput-java is an Arch: all package. I assume it's actually okay that it is uninstallable on some arches; FTP master can't very well remove it from those and not the others. src:jinput does also build libjinput-jni which is Arch: any, but that FTBFS on kfreebsd on sid/jessie: https://buildd.debian.org/status/package.php?p=jinput&suite=unstable I don't think it has ever built before on kfreebsd so, I don't think that could be an RC bug either? https://buildd.debian.org/status/logs.php?pkg=jinput&arch=kfreebsd-amd64 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765706: webkit2gtk: sometimes FTBFS[any-i386]: undefined method `[]' for nil:NilClass
Hi, On 28/10/14 09:43, Alberto Garcia wrote: > I didn't notice anything odd in the makefiles that could be causing > this problem, so I tried to reproduce it with no success. I rebuilt > webkit several times and it went fine in all cases. I also uploaded > 2.6.2 which built fine in all architectures. If the bug is still there, it probably would have been noticed on at least one of the architectures it built for. > https://anonscm.debian.org/cgit/pkg-webkit/webkit.git/diff/Source/JavaScriptCore/PlatformGTK.cmake?h=webkitgtk-2.6&id=2a5c18f331b7d2b3aa2b119a42d76a6655a47c62 > > I can try to confirm if that was the fix for the problem, else I guess > we can assume that the problem was in a build dependency. I don't think it matters; I don't see much point keeping the bug open, unless the problem comes back? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766913: chiark-utils: FTBFS[kfreebsd]: needs linux/acct.h
Package: chiark-utils Version: 4.4.0 Severity: serious Hi, chiark-utils fails to build acctdump.c on kfreebsd because: * #include on kfreebsd must be preceded by #include (for some integer typedefs) * kfreebsd's acct.h does not have a struct acct_v3 anyway, that is Linux-specific https://buildd.debian.org/status/fetch.php?pkg=chiark-utils&arch=kfreebsd-amd64&ver=4.4.0&stamp=1414340980 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766910: owfs: FTBFS[kfreebsd]: wrong ifdef __FreeBSD__
Package: owfs
Version: 2.9p8-3
Severity: serious
Tags: patch
Hi,
owfs still FTBFS on kfreebsd...
In freebsd.patch, the #ifdefs need to be __FreeBSD_kernel__ instead.
Please see attached. Then it builds fine on kfreebsd-amd64.
(You have only 15 minutes left until dinstall though).
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Better support for FreeBSD
--- a/module/owfs/src/c/owfs.c
+++ b/module/owfs/src/c/owfs.c
@@ -17,6 +17,9 @@
#include "owfs.h"
#include "ow_connection.h"
+#ifdef __FreeBSD_kernel__
+#include "sys/param.h"
+#endif
#include "sys/mount.h"
/*
@@ -129,7 +132,11 @@
// Unmount just in case
// No checks -- can fail without consequences
+#ifdef __FreeBSD_kernel__
+ unmount( Outbound_Control.head->name, 0);
+#else
umount( Outbound_Control.head->name ) ;
+#endif
Fuse_parse(fuse_mnt_opt, &fuse_options);
LEVEL_DEBUG("fuse_mnt_opt=[%s]", fuse_mnt_opt);
