Bug#1071319: marked as pending in libapache2-mod-auth-openidc

2024-05-31 Thread Moritz Schlarb
Control: tag -1 pending

Hello,

Bug #1071319 in libapache2-mod-auth-openidc reported by you has been fixed in 
the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/libapache2-mod-auth-openidc/-/commit/c8060a8cb588d43e513f55d764fdd8e7c868ec20


Remove RSA PKCS v1.5 JWE algorithm

Imported two upstream commits to allow building with cjose 0.6.2.3
again.

Closes: #1071319


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1071319



Bug#1071319: libapache2-mod-auth-openidc: FTBFS: test/test fails

2024-05-27 Thread Moritz Schlarb

Thanks for the report,

I suppose this is due to an algorithm support change in cjose - upstream 
fixed it in Git: 
https://github.com/OpenIDC/mod_auth_openidc/commit/1f2697468a505c66439117b769dbe6779d26968c


On 17.05.24 22:38, Santiago Vila wrote:

Package: src:libapache2-mod-auth-openidc
Version: 2.4.15.7-1
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
  debian/rules build
dh build --with apache2
    dh_update_autotools_config
    dh_autoreconf
aclocal: warning: couldn't open directory 'm4': No such file or directory
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:12: installing './ar-lib'
configure.ac:10: installing './compile'
configure.ac:13: installing './config.guess'
configure.ac:13: installing './config.sub'
configure.ac:5: installing './install-sh'
configure.ac:5: installing './missing'
Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
    dh_auto_configure
 ./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of gcc... none
checking for ar... ar
checking the archiver (ar) interface... ar
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to 
x86_64-pc-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain 
format... func_convert_file_noop

checking for /usr/bin/ld option to reload object files... -r
checking for file... file
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports 
shared libraries... yes

checking whether -lc shoul

Bug#1069336: marked as pending in seafile-client

2024-04-22 Thread Moritz Schlarb
Control: tag -1 pending

Hello,

Bug #1069336 in seafile-client reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/seafile-client/-/commit/758facd2f3c3ec44da432885c5e0cdc629d8bab8


Fix Dependencies (Closes: #1069336)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1069336



Bug#1000061: cfengine3: depends on obsolete pcre3 library

2023-12-19 Thread Moritz Schlarb

Control: tags -1 + patch

https://github.com/cfengine/core/pull/5391


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#891224: occurs in bullseye release

2022-02-23 Thread Moritz Schlarb

Oh wow, okay, yes...
Sorry. I'm probably just to tired for anything...

That issue looks familiar and in my Git Repo for 
libapache2-mod-auth-openidc I even have a tag called debian/2.4.9.4-1, 
so I probably already nearly solved this but apparently did not release...


Sorry about that!
I'll submit this to proposed-updates.

Thanks for you patience,
Moritz

On 23.02.22 11:11, Hamish Moffatt wrote:


It's listed as fixed in the upstream release notes for 2.4.9.2: 
https://github.com/zmartzone/mod_auth_openidc/releases/tag/v2.4.9.2



Regards
Hamish

On 23/2/22 20:57, Hamish Moffatt wrote:

Hi Moritz,

Even after a full restart (systemctl restart apache2), it still causes 
a segfault on every "apache2ctl graceful".


vagrant up (debian/bullseye64)
sudo -i
apt update
apt install apache2; apt install libapache2-mod-auth-openidc
systemctl restart apache2
apache2ctl graceful


/var/log/apache2/error says:

[Wed Feb 23 09:54:04.187005 2022] [core:notice] [pid 2554:tid 
140034803486016] AH00052: child pid 2678 exit signal Segmentation 
fault (11)


following every "apache2ctl graceful".



regards

Hamish



On 23/2/22 20:46, Moritz Schlarb wrote:

Dear Hamish,

sorry, I didn't think all the way through what you were writing.

Actually, enabling (and probably disabling) modules in Apache2 always 
requires a restart of the main daemon process - so performing a 
graceful restart/reload is simply not supported here (you are 
experiencing the actual reason for that).


That's also why I wasn't able to reproduce in the first place - 
because I restarted Apache after installing the Module out of muscle 
memory. ;-)


Hope that helps,
Moritz

On 17.01.22 00:55, Hamish Moffatt wrote:
I'm seeing this in bullseye with a brand new apache install. Every 
graceful restart (apache2ctl graceful) causes a segfault.


I don't have PHP or any other non-fault modules installed.

To reproduce: Set up fresh VM; apt install apache2; apt install 
libapache2-mod-auth-openidc; apache2ctl graceful



[Sun Jan 16 23:55:27.742953 2022] [mpm_event:notice] [pid 2412:tid 
140640895987008] AH00493: SIGUSR1 received.  Doing graceful restart
AH00558: apache2: Could not reliably determine the server's fully 
qualified domain name, using 127.0.0.2. Set the 'ServerName' 
directive globally to suppress this message
[Sun Jan 16 23:55:27.759267 2022] [mpm_event:notice] [pid 2412:tid 
140640895987008] AH00489: Apache/2.4.52 (Debian) configured -- 
resuming normal operations
[Sun Jan 16 23:55:27.759284 2022] [core:notice] [pid 2412:tid 
140640895987008] AH00094: Command line: '/usr/sbin/apache2'
[Sun Jan 16 23:55:27.759752 2022] [core:notice] [pid 2412:tid 
140640895987008] AH00052: child pid 2480 exit signal Segmentation 
fault (11)



This did not occur in buster.


Hamish








--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF



Bug#891224: occurs in bullseye release

2022-02-23 Thread Moritz Schlarb

Dear Hamish,

sorry, I didn't think all the way through what you were writing.

Actually, enabling (and probably disabling) modules in Apache2 always 
requires a restart of the main daemon process - so performing a graceful 
restart/reload is simply not supported here (you are experiencing the 
actual reason for that).


That's also why I wasn't able to reproduce in the first place - because 
I restarted Apache after installing the Module out of muscle memory. ;-)


Hope that helps,
Moritz

On 17.01.22 00:55, Hamish Moffatt wrote:
I'm seeing this in bullseye with a brand new apache install. Every 
graceful restart (apache2ctl graceful) causes a segfault.


I don't have PHP or any other non-fault modules installed.

To reproduce: Set up fresh VM; apt install apache2; apt install 
libapache2-mod-auth-openidc; apache2ctl graceful



[Sun Jan 16 23:55:27.742953 2022] [mpm_event:notice] [pid 2412:tid 
140640895987008] AH00493: SIGUSR1 received.  Doing graceful restart
AH00558: apache2: Could not reliably determine the server's fully 
qualified domain name, using 127.0.0.2. Set the 'ServerName' directive 
globally to suppress this message
[Sun Jan 16 23:55:27.759267 2022] [mpm_event:notice] [pid 2412:tid 
140640895987008] AH00489: Apache/2.4.52 (Debian) configured -- resuming 
normal operations
[Sun Jan 16 23:55:27.759284 2022] [core:notice] [pid 2412:tid 
140640895987008] AH00094: Command line: '/usr/sbin/apache2'
[Sun Jan 16 23:55:27.759752 2022] [core:notice] [pid 2412:tid 
140640895987008] AH00052: child pid 2480 exit signal Segmentation fault 
(11)



This did not occur in buster.


Hamish


--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF



Bug#891224: occurs in bullseye release

2022-02-23 Thread Moritz Schlarb

Dear Hamish,

can you please send us more information on your setup?

E.g. the output of:
apache2ctl -M
and
dpkg -l *apache*

Thanks,
Moritz

On 17.01.22 00:55, Hamish Moffatt wrote:
I'm seeing this in bullseye with a brand new apache install. Every 
graceful restart (apache2ctl graceful) causes a segfault.


I don't have PHP or any other non-fault modules installed.

To reproduce: Set up fresh VM; apt install apache2; apt install 
libapache2-mod-auth-openidc; apache2ctl graceful



[Sun Jan 16 23:55:27.742953 2022] [mpm_event:notice] [pid 2412:tid 
140640895987008] AH00493: SIGUSR1 received.  Doing graceful restart
AH00558: apache2: Could not reliably determine the server's fully 
qualified domain name, using 127.0.0.2. Set the 'ServerName' directive 
globally to suppress this message
[Sun Jan 16 23:55:27.759267 2022] [mpm_event:notice] [pid 2412:tid 
140640895987008] AH00489: Apache/2.4.52 (Debian) configured -- resuming 
normal operations
[Sun Jan 16 23:55:27.759284 2022] [core:notice] [pid 2412:tid 
140640895987008] AH00094: Command line: '/usr/sbin/apache2'
[Sun Jan 16 23:55:27.759752 2022] [core:notice] [pid 2412:tid 
140640895987008] AH00052: child pid 2480 exit signal Segmentation fault 
(11)



This did not occur in buster.


Hamish


--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF


OpenPGP_signature
Description: OpenPGP digital signature


Bug#891224: marked as pending in libapache2-mod-auth-openidc

2021-09-07 Thread Moritz Schlarb
Control: tag -1 pending

Hello,

Bug #891224 in libapache2-mod-auth-openidc reported by you has been
fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/libapache2-mod-auth-openidc/-/commit/428cdff0557c104ffe804c83cd1ff7dfae7f3f33


Update changelog for 2.4.9.4-1 release

   * New upstream version 2.4.9.4
   * Fix "CVE-2021-39191" (Closes: #993648)
   * 2.4.9.2 fixed a regression regarding segfault at reload/restart
 (Closes: #883616, #891224, #868949)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/891224



Bug#883616: marked as pending in libapache2-mod-auth-openidc

2021-09-07 Thread Moritz Schlarb
Control: tag -1 pending

Hello,

Bug #883616 in libapache2-mod-auth-openidc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/libapache2-mod-auth-openidc/-/commit/428cdff0557c104ffe804c83cd1ff7dfae7f3f33


Update changelog for 2.4.9.4-1 release

  * New upstream version 2.4.9.4
  * Fix "CVE-2021-39191" (Closes: #993648)
  * 2.4.9.2 fixed a regression regarding segfault at reload/restart
(Closes: #883616, #891224, #868949)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/883616



Bug#973363: marked as pending in node-uid-number

2020-10-29 Thread Moritz Schlarb

Hi Xavier,

thanks for the rapid fix!
Would you consider requesting to include this on the next point release?

Thanks a lot,
Moritz

On 29.10.20 14:00, Xavier Guimard wrote:

Control: tag -1 pending

Hello,

Bug #973363 in node-uid-number reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/js-team/node-uid-number/-/commit/d35c9664cf47910f82305cbe16e6833c4b95a888


Use dh-sequence-nodejs auto install

Closes: #973363


(this message was generated automatically)



--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF


OpenPGP_0x0C24B841C7DDBAAF.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature


Bug#973363: node-uid-number: package does not install get-uid-gid.js file from source

2020-10-29 Thread Moritz Schlarb
Package: node-uid-number
Version: 0.0.6-1
Severity: grave
Tags: patch
Justification: renders package unusable

The source for this package also includes a file named get-uid-gid.js which is
not installed with the package files.

This causes an unrelated npm/npx command to fail with:

18116 silly postinstall core-js@3.6.5
18117 info lifecycle core-js@3.6.5~postinstall: core-js@3.6.5
18118 verbose lifecycle core-js@3.6.5~postinstall: unsafe-perm in lifecycle
false
18119 verbose stack Error: Cannot find module './get-uid-gid.js'
18119 verbose stack at Function.Module._resolveFilename
(internal/modules/cjs/loader.js:636:15)
18119 verbose stack at Function.resolve
(internal/modules/cjs/helpers.js:33:19)
18119 verbose stack at uidNumber (/usr/lib/nodejs/uid-number/uid-
number.js:31:24)
18119 verbose stack at runCmd (/usr/share/npm/node_modules/npm-
lifecycle/index.js:267:5)
18119 verbose stack at runPackageLifecycle
(/usr/share/npm/node_modules/npm-lifecycle/index.js:228:3)
18119 verbose stack at Array. (/usr/lib/nodejs/slide/lib/bind-
actor.js:15:8)
18119 verbose stack at LOOP (/usr/lib/nodejs/slide/lib/chain.js:15:14)
18119 verbose stack at chain (/usr/lib/nodejs/slide/lib/chain.js:20:5)
18119 verbose stack at lifecycle_ (/usr/share/npm/node_modules/npm-
lifecycle/index.js:167:3)
18119 verbose stack at /usr/share/npm/node_modules/npm-
lifecycle/index.js:104:9
18119 verbose stack at /usr/share/npm/node_modules/npm-
lifecycle/index.js:218:12
18119 verbose stack at /usr/lib/nodejs/graceful-fs/polyfills.js:287:18
18119 verbose stack at FSReqWrap.oncomplete (fs.js:154:5)
18120 verbose cwd /tmp/bla
18121 verbose Linux 4.19.0-12-amd64
18122 verbose argv "/usr/bin/node" "/usr/share/npm/bin/npm-cli.js" "install"
"sb@latest" "--global" "--prefix" "/root/schlarbm/.npm/_npx/19136" "--loglevel"
"error" "--json"
18123 verbose node v10.21.0
18124 verbose npm  v6.14.8
18125 error code MODULE_NOT_FOUND
18126 error Cannot find module './get-uid-gid.js'
18127 verbose exit [ 1, true ]



-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable'), (60, 'testing'), (50, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-12-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages node-uid-number depends on:
ii  nodejs  10.21.0~dfsg-1~deb10u1

node-uid-number recommends no packages.

node-uid-number suggests no packages.



Bug#963280: marked as pending in seafile-client

2020-07-08 Thread Moritz Schlarb
Control: tag -1 pending

Hello,

Bug #963280 in seafile-client reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/seafile-client/-/commit/dbc3d86b5e6d5aa7c1709586bad642f1af907587


Update QuaZip Patch

Closes: #963280


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/963280



Bug#938459: marked as pending in seafile

2020-01-20 Thread Moritz Schlarb
Control: tag -1 pending

Hello,

Bug #938459 in seafile reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/seafile/commit/ceac51debf8a9f96eadd595db64c917e994e3abe


Fix shebang in seaf-cli for Python 3

(Closes: #938459)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/938459



Bug#943789: marked as pending in seafile-client

2019-10-30 Thread Moritz Schlarb
Control: tag -1 pending

Hello,

Bug #943789 in seafile-client reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/seafile-client/commit/6357096e0c0bbf710fe0196b460c9e96b14a1325


Fix versioned dependencies (Closes: #943789)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/943789



Bug#942165: CVE-2019-14857

2019-10-16 Thread Moritz Schlarb
Same for stretch:
https://salsa.debian.org/debian/libapache2-mod-auth-openidc/commit/e0b3eac21212b12562721ab3c903c4f24eef9e8f

On 16.10.19 11:19, Moritz Schlarb wrote:
> Hi everyone,
> 
> I have prepared a backport of the patches for the version packaged in
> Buster:
> https://salsa.debian.org/debian/libapache2-mod-auth-openidc/commit/17e31b94a71ef02d1417bee6b0ef7b7379b40375
> 
> If you deem necessary and sufficient, please release as a security
> update or otherwise I'll try to get it in in proposed-updates.
> 
> Regards,
> Moritz (another one)
> 
> On 11.10.19 10:14, Moritz Muehlenhoff wrote:
>> Package: libapache2-mod-auth-openidc
>> Severity: grave
>> Tags: security
>>
>> Please see: 
>> https://groups.google.com/forum/#!topic/mod_auth_openidc/boy1Ba3Gdk4
>>
>> https://github.com/zmartzone/mod_auth_openidc/commit/5c15dfb08106c2451c2c44ce7ace6813c216ba75
>> https://github.com/zmartzone/mod_auth_openidc/commit/ce37080c6aea30aabae8b4a9b4eea7808445cc8e
>> https://github.com/zmartzone/mod_auth_openidc/pull/451
>>
>> Cheers,
>> Moritz
>> 
>>
> 

-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF



signature.asc
Description: OpenPGP digital signature


Bug#942165: CVE-2019-14857

2019-10-16 Thread Moritz Schlarb
Hi everyone,

I have prepared a backport of the patches for the version packaged in
Buster:
https://salsa.debian.org/debian/libapache2-mod-auth-openidc/commit/17e31b94a71ef02d1417bee6b0ef7b7379b40375

If you deem necessary and sufficient, please release as a security
update or otherwise I'll try to get it in in proposed-updates.

Regards,
Moritz (another one)

On 11.10.19 10:14, Moritz Muehlenhoff wrote:
> Package: libapache2-mod-auth-openidc
> Severity: grave
> Tags: security
> 
> Please see: 
> https://groups.google.com/forum/#!topic/mod_auth_openidc/boy1Ba3Gdk4
> 
> https://github.com/zmartzone/mod_auth_openidc/commit/5c15dfb08106c2451c2c44ce7ace6813c216ba75
> https://github.com/zmartzone/mod_auth_openidc/commit/ce37080c6aea30aabae8b4a9b4eea7808445cc8e
> https://github.com/zmartzone/mod_auth_openidc/pull/451
> 
> Cheers,
> Moritz
> 
> 

-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF



signature.asc
Description: OpenPGP digital signature


Bug#913405: Bug #913405 in seafile marked as pending

2018-11-12 Thread Moritz Schlarb
Control: tag -1 pending

Hello,

Bug #913405 in seafile reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/debian/seafile/commit/0122dc2fb7ad059b1b73cb0f8d70610b365283f9


Add Breaks: seafile-gui (<= 6.2.5) (Closes: #913405)



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/913405



Bug#902947: seafile-daemon and seafile-cli are unusable in 6.2.0

2018-07-03 Thread Moritz Schlarb
Source: seafile
Version: 6.2.0-1
Severity: serious
Tags: upstream
Justification: Policy 3.5

This bug is mainly to prevent migration of the 6.2.0 package.

Upstream is working on removing the ccnet dependency, but right now they've
only done that for the non-python parts of the package.



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



Bug#890907:

2018-05-23 Thread Moritz Schlarb
Hi Adrian,

yeah, that didn't work out...

If you have time, would you mind looking at our analysis at
https://github.com/cisco/cjose/issues/70 where we gathered our findings?

Best wishes,
Moritz

On 20.05.2018 15:36, Adrian Bunk wrote:
> Control: reopen -1
> 
> On Wed, May 16, 2018 at 08:39:03PM +, Debian Bug Tracking System wrote:
>> ...
>>  cjose (0.6.0+dfsg1-2~exp1) experimental; urgency=medium
>> ...
>>* Test upstream patch from
>>  https://github.com/cisco/cjose/pull/71 (Closes: #890907)
>> ...
> 
> Seems this didn't work:
> https://buildd.debian.org/status/package.php?p=cjose&suite=experimental
> 
> cu
> Adrian
> 

-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature


Bug#897214: Fixed in 6.1.7-1

2018-04-30 Thread Moritz Schlarb
Control: fixed -1 seafile-cli/6.1.7-1
Control: tags -1 + fixed pending

This will be resolved as soon as src:seafile/6.1.7-1 finally migrates...

-- 
Moritz Schlarb



Bug#893039: libccnet0: contains a python module

2018-04-20 Thread Moritz Schlarb
Hello Helmut,

On 20.04.2018 20:06, Helmut Grohne wrote:
> I just looked into the package and only then noticed Christoph's upload.
> Let me share a few remarks though:
> 
>  * The new upstream release is a bit "strange". Even github uses the
>same commit id for both 6.1.5 and 6.1.7. That looks like a mistake to
>me.

It is a deliberate decision made by upstream to ensure that the three
components of the Seafile client "suite" always use the same version
number... Therefore they always re-tag ccnet, even if there are no
changes in the meantime. (Strangely, for searpc, they don't do that, but
use an even stranger tagging scheme, where there's currently only a Git
tag v3.1-latest, though the "internal" version is [correctly] set to
3.0.8...).
We decided to just follow along this decision by upstream since just
rebuilding the package with a new version is only minorly inconvenient
and we wanted to not divert too much from their recommendation. Although
I just now thought that if we think this trough, we should also have
strict same-version dependencies between the three components, which we
don't have right now.

>  * Did you consider porting to Python 3? It seems that for searpc, there
>is a patch to support Python 3 at
>https://github.com/haiwen/libsearpc/pull/21.

I noticed the Lintian warning and did not override it to keep it as a
marker to do that soon.

Best regards,
Moritz



Bug#893039: libccnet0: contains a python module

2018-04-17 Thread Moritz Schlarb
Hi Helmut,

I addressed this issue in 6.1.5-2, but since this leads to a new binary
upload, I can't upload it myself since I'm just a DM.
My mentor/sponsor Christoph is currently out of the office, so he can't
do it either.
So I've uploaded it to https://mentors.debian.net/package/ccnet - maybe
you are willing to perform the upload for me (If that went through, I'm
gonna upload the new upstream version myself).

Best regards,
Moritz



signature.asc
Description: OpenPGP digital signature


Bug#895467: libsearpc FTBFS on 64bit big endian: test failure

2018-04-16 Thread Moritz Schlarb
Hi Adrian and thanks for your response,

On 16.04.2018 15:13, Adrian Bunk wrote:
> Third solution:
> Fix the bugs.

Well that was actually the first solution I meant, but I just didn't
have much hope finding a solution, so thank you very much for your help.

> After fixing the two above bugs, libsearpc builds on s390x.

I've added patches to the package and will send them upstream.

> An en passant finding (not required to fix the FTBFS) is the following 
> that is documented to be unsupported, and might break on any 
> architecture at any time:
> https://sources.debian.org/src/libsearpc/3.0.8-3/lib/searpc-named-pipe-transport.c/#L236

I will report that to upstream, too.

Thx,
Moritz



signature.asc
Description: OpenPGP digital signature


Bug#895467: libsearpc FTBFS on 64bit big endian: test failure

2018-04-16 Thread Moritz Schlarb
Hi there,

I'm unsure how to handle this.

The current breakage of the package since 3.0.8-2 comes from me
re-enabling the upstream tests, which were previously disabled with a
comment that they were broken upstream (so, at
https://buildd.debian.org/status/logs.php?pkg=libsearpc&ver=3.0.8-1, all
builds ran fine but right now, they fail on some architectures - s390x,
ppc64 and sparc64:
https://buildd.debian.org/status/package.php?p=libsearpc).

Since the package still builds and tests fine on *most* architectures,
I'd beg to differ that the test suite is broken in general.

Now of course myself and upstream can look into the problem, but since
it maybe is specific to an exotic architecture that we might not have
access to, I would not have high hopes in that approach.

Two other "solutions", I can think of would be:
- Using a switch on the current architecture in debian/rules to just
don't test on these arches
- Exclude the arches from Architecture: in debian/control

Would any of those options be appropriate?

Best regards,
Moritz

On 11.04.2018 22:24, Adrian Bunk wrote:
> Source: libsearpc
> Version: 3.0.8-2
> Severity: serious
> 
> https://buildd.debian.org/status/package.php?p=libsearpc&suite=sid
> 
> ...
> FAIL: test-searpc
> =
> 
> Loaded 1 suites: 
> Started
> 
> (process:10121): Searpc-WARNING **: 17:59:21.601: failed to read rpc request: 
> Bad address
> 
> (process:10121): Searpc-WARNING **: 17:59:21.601: failed to read rpc 
> response: Connection reset by peer
> F
> (process:10121): Searpc-WARNING **: 17:59:21.923: failed to read rpc request: 
> Bad address
> 
> (process:10121): Searpc-WARNING **: 17:59:21.923: failed to send rpc call: 
> Broken pipe
> F
> (process:10121): Searpc-WARNING **: 17:59:22.122: failed to read rpc request: 
> Bad address
> 
> (process:10121): Searpc-WARNING **: 17:59:22.125: failed to read rpc 
> response: Connection reset by peer
> F
> 
>   1) Failure:
> searpc::pipe_simple_call [searpc.c:427]
>   Expression is not true: error == NULL
>   Transport Error
> 
>   2) Failure:
> searpc::pipe_large_request [searpc.c:454]
>   Expression is not true: error == NULL
>   Transport Error
> 
>   3) Failure:
> searpc::pipe_concurrent_clients [searpc.c:483]
>   Expression is not true: error == NULL
>   Transport Error
> 
> System error: `fork()` call failed (12) - Cannot allocate memory
> FAIL test-searpc (exit status: 255)
> 
> 
> Testsuite summary for libsearpc 3.0.8
> 
> # TOTAL: 1
> # PASS:  0
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> See tests/test-suite.log
> Please report to i...@seafile.com
> 
> make[5]: *** [Makefile:687: test-suite.log] Error 1
> 



Bug#859716: Patch from upstream commit

2017-11-23 Thread Moritz Schlarb
Upstream has just committed the following, which we could probably use
as a patch in the meantime:

> From 3a547b8ab392e0419488eb4aa633f9b31f0ccaf4 Mon Sep 17 00:00:00 2001
> From: Jonathan Xu 
> Date: Tue, 21 Nov 2017 19:56:31 +0800
> Subject: [PATCH] Replace deprecated generate_rsa_key() with
>  generate_rsa_key_ex().
> 
> ---
>  src/utils/rsa.cpp | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/src/utils/rsa.cpp b/src/utils/rsa.cpp
> index 4f923add0..cbaefbe11 100644
> --- a/src/utils/rsa.cpp
> +++ b/src/utils/rsa.cpp
> @@ -177,8 +177,12 @@ id_from_pubkey (RSA *pubkey)
>  RSA *
>  generate_private_key(u_int bits)
>  {
> - RSA *priv = NULL;
> +RSA *priv = RSA_new ();
> +BIGNUM *e = BN_new ();
>  
> - priv = RSA_generate_key(bits, 35, NULL, NULL);
> - return priv;
> +BN_set_word (e, 35);
> +RSA_generate_key_ex (priv, bits, e, NULL);
> +
> +BN_free (e);
> +return priv;
>  }
> 

Best regards,

-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
>From 3a547b8ab392e0419488eb4aa633f9b31f0ccaf4 Mon Sep 17 00:00:00 2001
From: Jonathan Xu 
Date: Tue, 21 Nov 2017 19:56:31 +0800
Subject: [PATCH] Replace deprecated generate_rsa_key() with
 generate_rsa_key_ex().

---
 src/utils/rsa.cpp | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/utils/rsa.cpp b/src/utils/rsa.cpp
index 4f923add0..cbaefbe11 100644
--- a/src/utils/rsa.cpp
+++ b/src/utils/rsa.cpp
@@ -177,8 +177,12 @@ id_from_pubkey (RSA *pubkey)
 RSA *
 generate_private_key(u_int bits)
 {
-	RSA *priv = NULL;
+RSA *priv = RSA_new ();
+BIGNUM *e = BN_new ();
 
-	priv = RSA_generate_key(bits, 35, NULL, NULL);
-	return priv;
+BN_set_word (e, 35);
+RSA_generate_key_ex (priv, bits, e, NULL);
+
+BN_free (e);
+return priv;
 }
<>

Bug#861152: Bug#861725: unblock: nagstamon/2.0.1-4

2017-05-03 Thread Moritz Schlarb
Hi Julien, hi Paul,

On 03.05.2017 11:51, Julien Cristau wrote:
> I don't see how not checking certificates is in any way a reasonable
> thing to do.  Silencing warnings about it makes it even worse.

Absolutely true - but:

- This has been the behavior of the Nagstamon package since forever
(which is not a valid argumentation point - I know, but it's still a fact)
- It is actually the intended behavior by the upstream developer (until
https://github.com/HenriWahl/Nagstamon/issues/302 gets resolved) - the
added patch just actually makes the disabling of warnings work (which
worked before in jessie but not anymore in stretch)
- We anticipated the concerns regarding not checking certificates and
wrote a paragraph in README.debian about our rationale for accepting
that with regards to the primary type of user of such monitoring software

On 03.05.2017 11:32, Paul Wise wrote:
> I don't think the warnings should be disabled,
> I think that the certificates should be verified.
> Why are the warnings being disabled?

Because upstream chose to do so - I want to stress again that my patch
just fixes the code to actually do what upstream wanted it to do.

Now whether these warnings are disabled or not isn't the real problem
here - that should be clear.
But it was because of these warnings (which, again, do not come from a
change in behavior but just in reporting it), that Paul reported #861152
and tagged it as release critical which lead to the package being put in
the removal queue...

If you'd like, we can explicitly re-enable the warnings so the behavior
is visible to the users.
But I don't want to have nagstamon removed simply because of that...

What do you think?

Regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-321 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature


Bug#861152: A fix for the warning

2017-04-28 Thread Moritz Schlarb
Control: tags -1 + stretch

I have fixed the code for disabling the warnings which didn't work in
Stretch, because there were some changes regarding the requests.packages
unbundling in python3-requests.

https://anonscm.debian.org/viewvc/python-apps?view=revision&revision=13981

Still, I'd like for upstream to handle that better - but that isn't
going to happen right now.

Regards,
Moritz



Bug#861152: nagstamon: InsecureRequestWarning: Unverified HTTPS request is being made.

2017-04-25 Thread Moritz Schlarb
Control: forwarded -1 https://github.com/HenriWahl/Nagstamon/issues/302
Control: tags -1 + upstream confirmed

Hi Paul,

On Tue, 25 Apr 2017 11:27:01 +0800 Paul Wise  wrote:
> Severity: serious
> Tags: security
> 
> When I run nagstamon from a terminal against the Debian nagios I get a
> warning about unverified and thus insecure HTTPS requests being made:
> 
> ...
> /usr/lib/python3/dist-packages/urllib3/connectionpool.py:845: 
> InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
> certificate verification is strongly advised. See: 
> https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
> Â  InsecureRequestWarning)

Now stuff is getting interesting...

I think upstream is thinking different about the severity of this
behaviour. In other parts of the code, these urllib3 warnings are
explicitly being disabled:
https://github.com/HenriWahl/Nagstamon/blob/master/Nagstamon/Servers/Generic.py#L24
So it just doesn't get noticed there although the behaviour is the same.

This explicit neglection of verifying HTTPS connections was added in
https://github.com/HenriWahl/Nagstamon/issues/126
which also had a Debian bug at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774687

There also is already an upstream equivalent of this bug report:
https://github.com/HenriWahl/Nagstamon/issues/302

Now is the current behaviour really a policy violation (if so, please
help me by pointing to the correct source for that) or would you be open
to lowering the severity of this bug?

Regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-321 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>