Bug#962105: znc: CVE-2020-13775
03.06.2020 11:25, Salvatore Bonaccorso пишет: > Source: znc > Version: 1.8.0-1 > Severity: important > Tags: security upstream > > Hi, > > The following vulnerability was published for znc. > > CVE-2020-13775[0]: > | ZNC before 1.8.1-rc1 allows attackers to trigger an application crash > | (with a NULL pointer dereference) if echo-message is not enabled and > | there is no network. > > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2020-13775 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13775 > [1] https://github.com/znc/znc/commit/2390ad111bde16a78c98ac44572090b33c3bd2d8 > > Please adjust the affected versions in the BTS as needed, if my > understandig of the isuse is correctly then this was only introduced > in 1.8.0 while fixing another bug related to echo-messages, please > double check though. Correct. MITRE changed the suggested description and left that and a few more details out. https://wiki.znc.in/ChangeLog/1.8.1 has a better text. > > Regards, > Salvatore > -- Best regards, Alexey "DarthGandalf" Sokolov
Bug#925270: znc unwisely advertises exact Debian version
22.03.2019 8:08, Uli Schlachter пишет: > Hi, > > On 22.03.19 00:53, T. Joseph Carter wrote: >> <-- nick (~u@h) has quit (Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in) >> <-- nick (~u@h) has quit (Quit: ZNC 1.6.6+deb1ubuntu0.1 - http://znc.in) >> <-- nick (~u@h) has quit (Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in) >> >> And one counter-example of how changing the default might be a good idea: >> >> <-- nick (~u@h has quit (Quit: ZNC - https://znc.in) > > This behaviour goes back to [1], I think. Before that, ZNC would do the > second kind of quit message. Commit [1] introduced an option called > "HideVersion", which defaults to "false". If this option is "false", the > function CZNC::GetTag() *always* includes version information. When set > to "true", CZNC::GetTag() only includes version information when told so > by its caller (seems to be: only the web interface for logged-in users). No, before that commit, ZNC sometimes did expose the version, sometimes did not. That commit made it consistent, and configurable. I made it false by default to follow example of other software which exposes its version, e.g. nginx. > When I proposed to restore the old behaviour and instead to make > "HideVersion" also not include the version when explicitly told > otherwise, I was told that this is the way it is supposed to work. > AFAIR, the patch you proposed caused it to always hide the version, even for logged in users, and in znc --version > Anyway: Set "HideVersion = true" in your znc to get rid of the version > information. Webadmin can modify this setting, but controlpanel can not. > > If wanted, Debian could patch src/znc.cpp to change the default for > m_bHideVersion to true (the line looks like "m_bHideVersion(false)"). > > Cheers, > Uli > > [1]: > https://github.com/znc/znc/commit/f9a45076690990f75a14315db4f456e750073723 > -- Best regards, Alexey "DarthGandalf" Sokolov
Bug#914783: Switch znc to cmake build
Package: znc Version: 1.7.1-2+b1 Hi Patrick Upstream added support for CMake in 1.7.0, and soft-deprecated autoconf. That is, eventually configure.ac will be removed, but for now, both are available, and configure.ac simply doesn't get any new features. E.g. i18n is now available only if ZNC was built using CMake, therefore not included to znc package. The change may be either to call cmake directly, or to use configure.sh wrapper provided by upstream, which accepts most of the same parameters which old configure script accepted. As a caveat, currently znc-buildmod gets turned into a python script when built with CMake, which would need dependency changes of znc-dev package. -- Best regards, Alexey "DarthGandalf" Sokolov
Bug#820517: (no subject)
Hi Can we just drop znc-tcl package? It's not necessary for the rest of ZNC, and is rarely used. But I'm going to release ZNC 1.7 soon where this is fixed. -- Best regards, Alexey "DarthGandalf" Sokolov
Bug#858205: Update ZNC package to 1.6.5
These files are generated. If it's from tarballs... Perhaps I upgraded my SWIG and autoconf to newer versions between packing tarballs for 1.6.4 and 1.6.5. You can safely ignore the diffs which are not in https://github.com/znc/znc/compare/znc-1.6.4...znc-1.6.5 But I don't know how mixing files from 1.6.4 and 1.6.5 tarballs would affect debian package version number. 2017-03-29 13:41 GMT+01:00 Patrick Matthäi : > $ diff -Naur znc-1.6.4 znc-1.6.5|diffstat > ChangeLog.md|9 > config.guess| 28 > config.sub | 22 > configure | 20 > configure.ac|2 > include/znc/version.h |4 > modules/modperl/ZNC.cpp | 334 + > modules/modperl/ZNC.pm |2 > modules/modperl/startup.pl |1 > modules/modperl/swigperlrun.h | 15 > modules/modpython/_znc_core.cpp | 7094 > ++-- > modules/modpython/swigpyrun.h | 116 > modules/modpython/znc.py|3 > modules/modpython/znc_core.py | 400 +- > modules/sasl.cpp|2 > 15 files changed, 4478 insertions(+), 3574 deletions(-) > > > Am 28.03.2017 um 13:32 schrieb Alexey Sokolov: >> Hi Patrick, >> Are you looking at the right versions? >> https://github.com/znc/znc/compare/znc-1.6.4...znc-1.6.5 is much >> smaller than what you've shown. >> >> 2017-03-28 11:19 GMT+01:00 Patrick Matthäi : >>> Am 19.03.2017 um 19:41 schrieb Thomas Ward: >>>> Source: znc >>>> Severity: wishlist >>>> >>>> Hello. >>>> >>>> ZNC 1.6.5 [1], which fixes several segfault risks in 1.6.4 modules and >>>> other behavior bugfixes, has been released. Can we update the ZNC >>>> package to 1.6.5? >>>> >>>> >>>> Thank you. >>>> >>>> >>>> [1]: http://wiki.znc.in/ChangeLog/1.6.5 >>> Hi, >>> >>> there are a lot more of changes, since we are in freeze I need the >>> commit ids: >>> 15 files changed, 4478 insertions(+), 3574 deletions(-) >>> >>> -- >>> /* >>> Mit freundlichem Gruß / With kind regards, >>> Patrick Matthäi >>> GNU/Linux Debian Developer >>> >>> Blog: http://www.linux-dev.org/ >>> E-Mail: pmatth...@debian.org >>> patr...@linux-dev.org >>> */ >>> > > -- > /* > Mit freundlichem Gruß / With kind regards, > Patrick Matthäi > GNU/Linux Debian Developer > > Blog: http://www.linux-dev.org/ > E-Mail: pmatth...@debian.org > patr...@linux-dev.org > */ >
Bug#858205: Update ZNC package to 1.6.5
Hi Patrick, Are you looking at the right versions? https://github.com/znc/znc/compare/znc-1.6.4...znc-1.6.5 is much smaller than what you've shown. 2017-03-28 11:19 GMT+01:00 Patrick Matthäi : > Am 19.03.2017 um 19:41 schrieb Thomas Ward: >> Source: znc >> Severity: wishlist >> >> Hello. >> >> ZNC 1.6.5 [1], which fixes several segfault risks in 1.6.4 modules and >> other behavior bugfixes, has been released. Can we update the ZNC >> package to 1.6.5? >> >> >> Thank you. >> >> >> [1]: http://wiki.znc.in/ChangeLog/1.6.5 > > Hi, > > there are a lot more of changes, since we are in freeze I need the > commit ids: > 15 files changed, 4478 insertions(+), 3574 deletions(-) > > -- > /* > Mit freundlichem Gruß / With kind regards, > Patrick Matthäi > GNU/Linux Debian Developer > > Blog: http://www.linux-dev.org/ > E-Mail: pmatth...@debian.org > patr...@linux-dev.org > */ >
Bug#734442: patch
> Cool. Outside of packaging, there are probably some hardening options > that would be useful to add. Have you considered adding socket > activation support, sd_notify and syslogging support to make this work > a little better with systemd? I'd be happy to contribute some > patches. Unless there are open bugs about it, probably it wasn't considered yet. Bigger integration with systemd is fine, but it should stay optional. ZNC shouldn't fail to start if it was compiled with the systemd support, but systemd is not presented during runtime. http://wiki.znc.in/Adminlog supports syslogging a bit, but there is big room for improvement, e.g. https://github.com/znc/znc/issues/32
Bug#734442: patch
No, the reason I reverted it is https://github.com/znc/znc/issues/1165#issuecomment-156880251 (point 2.) To repeat myself: If you guys (packagers) all agree on how this file should look like, I'm fine with it too. If you want to maintain a separate unit file for Debian which is different from other distros, I'm not in a position to stop you from doing this. I'm happy to accept changes upstream, if that makes packagers' life easier. You can join that discussion if you disagree with @seblu and @Philantrop As for _znc username, perhaps that could be either a Debian-specific one-line patch, or e.g. a env variable used by ./configure... 29.12.2015 22:30, Eric Dorland пишет: > * Alexey Sokolov (ale...@asokolov.org) wrote: >> Hi Eric, Does the service file need to be different from the >> included one? >> (https://github.com/znc/znc/blob/master/znc.service.in) > > Currently it does, because the patch as is creates a _znc user > rather than znc to avoid namespace collision. It also uses the > --datadir flag to avoid the .znc directory. It also uses > ConditionFileNotEmpty to prevent startup if it's not configured. We > don't have to do these things but they all seem useful to me. > There's really room to go further with various systemd protection > settings, but I didn't want to overcomplicate the diff. > >> Also please check the recent discussion about it at >> https://github.com/znc/znc/issues/1165 > > Thanks for pointing this out. There's a lot of issues to intermixed > in this bug report. It looks like the reason they reverted the > --datadir change was because it broke existing users, which is fair > but we don't have that problem in Debian. I think having a unified > unit file would be good but I don't think that should tie hands > against good improvements. >
Bug#734442: patch
Hi Eric, Does the service file need to be different from the included one? (https://github.com/znc/znc/blob/master/znc.service.in) Also please check the recent discussion about it at https://github.com/znc/znc/issues/1165
Bug#804618: znc: FTBFS: error: ‘SSLv3_client_method’ was not declared in this scope
Hi, This is fixed upstream in upcoming 1.6.2. I hope to release it in several days. Upstream reference: https://github.com/znc/znc/issues/1146 2015-11-09 21:25 GMT+00:00 Chris West (Faux) : > Source: znc > Version: 1.6.1-1 > Severity: serious > Justification: fails to build from source > Tags: sid stretch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > The package fails to build: > > src/Csocket.cpp: In member function ‘virtual bool Csock::SSLClientSetup()’: > src/Csocket.cpp:1467:48: error: ‘SSLv3_client_method’ was not declared in > this scope >m_ssl_ctx = SSL_CTX_new( SSLv3_client_method() ); > ^ > src/Csocket.cpp: In member function ‘SSL_CTX* Csock::SetupServerCTX()’: > src/Csocket.cpp:1589:43: error: ‘SSLv3_server_method’ was not declared in > this scope >pCTX = SSL_CTX_new( SSLv3_server_method() ); >^ > Makefile:116: recipe for target 'src/Csocket.o' failed > make[2]: *** [src/Csocket.o] Error 1 > make[2]: Leaving directory '/znc-1.6.1' > > Full build log: > https://reproducible.debian.net/rb-pkg/unstable/amd64/znc.html > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) >
Bug#672035: using std::pair
> I am unsure though if this is really the issue that building znc runs > into. It seems to happen only with "using std::pair", which the znc > sources do not do. ZNC has this statement in Utils.h, which is %include'd to modpython.i Your patch to modpython.i got merged to upstream ZNC, thanks. So I guess, we'll need to release new version soon. -- Best regards, Alexey "DarthGandalf" Sokolov signature.asc Description: OpenPGP digital signature
Bug#672035: [Swig-user] Using own string class
27.05.2012 04:14, William S Fulton пишет: > I can't replicate this bug with 2.0.6, you are going to have to > provide a test case. swig-2.0.5 introduced a regression which was > fixed in 2.0.7 - incorrect typemaps for templates were being used in > conjunction with typedef. Please try 2.0.7 and report back if fixed. > > William 2.0.7 shows the errors too. The minimal test case is attached. Run: swig -python -c++ test.i If to use %template(StrPair) std::pair; instead of "using std::pair", swig executes fine. I didn't test the generated code though. -- Best regards, Alexey "DarthGandalf" Sokolov %module test %include using std::pair; %template(StrPair) pair; signature.asc Description: OpenPGP digital signature
Bug#672035: Using own string class
Hello! At ZNC we have an own string class CString, which is inherited from std::string. The goal is to use it as a just string in target languages. How to do that properly? When I was writing modperl and modpython ZNC modules, I used an approach described at http://old.nabble.com/Forward-declaration-error--td24064356.html Used "swig -E" on std_string.i, got a long file as a result, cleaned it up and changed all occurences of std::string to CString. It worked fine before SWIG 2.0.5, but in 2.0.5 it started to give errors while generating sources for modpython: /usr/share/swig/2.0.6/std/std_pair.i:31: Error: Can't copy typemap (directorout) std::pair< CString,CString > = std::pair< CString,CString > &DIRECTOROUT /usr/share/swig/2.0.6/std/std_pair.i:31: Error: Can't copy typemap (in) std::pair< CString,CString > *INPUT = std::pair< CString,CString > *INOUT /usr/share/swig/2.0.6/std/std_pair.i:31: Error: Can't copy typemap (in) std::pair< CString,CString > &INPUT = std::pair< CString,CString > &INOUT /usr/share/swig/2.0.6/std/std_pair.i:31: Error: Can't copy typemap (typecheck) std::pair< CString,CString > *INPUT = std::pair< CString,CString > *INOUT /usr/share/swig/2.0.6/std/std_pair.i:31: Error: Can't copy typemap (typecheck) std::pair< CString,CString > &INPUT = std::pair< CString,CString > &INOUT /usr/share/swig/2.0.6/std/std_pair.i:31: Error: Can't copy typemap (argout) std::pair< CString,CString > *OUTPUT = std::pair< CString,CString > *INOUT /usr/share/swig/2.0.6/std/std_pair.i:31: Error: Can't copy typemap (argout) std::pair< CString,CString > &OUTPUT = std::pair< CString,CString > &INOUT /usr/share/swig/2.0.6/std/std_pair.i:31: Error: Can't copy typemap (typecheck) std::pair< CString,CString > *INPUT = std::pair< CString,CString > *INOUT /usr/share/swig/2.0.6/std/std_pair.i:31: Error: Can't copy typemap (typecheck) std::pair< CString,CString > &INPUT = std::pair< CString,CString > &INOUT /usr/share/swig/2.0.6/std/std_pair.i:31: Error: Can't copy typemap (freearg) std::pair< CString,CString > *INPUT = std::pair< CString,CString > *INOUT /usr/share/swig/2.0.6/std/std_pair.i:31: Error: Can't copy typemap (freearg) std::pair< CString,CString > &INPUT = std::pair< CString,CString > &INOUT Sending copy of the letter to 672...@bugs.debian.org Also there is related issue #174 on github/znc. -- Best regards, Alexey "DarthGandalf" Sokolov signature.asc Description: OpenPGP digital signature
Bug#666405: Fwd: Re: [Pkg-openssl-devel] Bug#666405: Info received (Backtraces of the crash, on ZNC with Android client)
I was building openssl from debian wheezy sources, with that patch applied... It seems that it helps, yes. PS. Ups, sent the letter to the wrong address first time. signature.asc Description: OpenPGP digital signature
Bug#666405: Info received (Backtraces of the crash, on ZNC with Android client)
(gdb) info reg rax0xdf7acb17 3749366551 rbx0xff2d -211 rcx0x79 121 rdx0x0 0 rsi0x12 18 rdi0x98b3f8 10007544 rbp0x985a5a 0x985a5a rsp0x7fffd680 0x7fffd680 r8 0xfffb 4294705151 r9 0xa3b2d70d 2746406669 r100xd6 214 r110x10 16 r120x985a5a 9984602 r130x0 0 r140x985a58 9984600 r150x985a58 9984600 rip0x77638431 0x77638431 eflags 0x10282 [ SF IF RF ] cs 0xe033 57395 ss 0xe02b 57387 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 2.80GHz stepping: 8 cpu MHz : 2793.280 cache size : 2048 KB fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc pni cid cx16 hypervisor lahf_lm bogomips: 5586.56 clflush size: 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 2.80GHz stepping: 8 cpu MHz : 2793.280 cache size : 2048 KB fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc pni cid cx16 hypervisor lahf_lm bogomips: 5586.56 clflush size: 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: -- Best regards, Alexey "DarthGandalf" Sokolov signature.asc Description: OpenPGP digital signature
Bug#565380: fix
Current Terence's implementation violates CAP specs. Now xchat looks only to first capability returned by server. This patch makes xchat to look the whole cap list, not only the first one. http://ssh.shellium.org/~somebody/xchat.patch.txt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
