Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
---|---|---|---|---|---|---|
0001-conf-makefile | Install config examples under /usr/share/doc | =?utf-8?q?Frederik_Sch=C3=BCler?= <fs@debian.org> | no | 2019-07-17 | ||
0002-use-docbook-xsl.patch | Use local docbook XSL sheets | Apollon Oikonomopoulos <apoikos@debian.org> | no | 2014-05-13 | ||
0003-use-dpkg-buildflags.patch | Use hardened LDFLAGS and CPPFLAGS | Apollon Oikonomopoulos <apoikos@debian.org> | no | 2014-05-13 | ||
0004-do-not-build-html-manpages.patch | Do not build the HTML manpages | Apollon Oikonomopoulos <apoikos@debian.org> | no | 2014-05-13 | ||
0005-fix-aio-detection.patch | Search for eventfd.h in /usr/include/<triplet> | Apollon Oikonomopoulos <apoikos@debian.org> | invalid | 2016-01-19 | ||
0006-fix-pie-build | Fix build with -fPIE Upstream's build system does not differentiate between the flags used for building shared libraries and those used for building shared libraries. As a result, it uses -fPIC everywhere, which is incompatible with -fPIE. To allow -fPIE to work for binaries, we must pass -fPIC to shared objects only and filter -fPIE and -pie out of CFLAGS and LDFLAGS when passed to shared libraries. |
Apollon Oikonomopoulos <apoikos@debian.org> | no | 2016-06-24 | ||
0007-Fix-compilation-with-glusterfs-6.patch | Fix compilation with glusterfs >= 6 GlusterFS 6 (API version 7.6) changed the signatures for some functions, by extending their signatures. This breaks tgt's build, so fix it by checking the GlusterFS API version and re-defining the affected functions. |
Apollon Oikonomopoulos <apoikos@debian.org> | no | 2019-07-17 | ||
0008-Fix-example-config-path-in-manpages.patch | Fix example config path in manpages | Apollon Oikonomopoulos <apoikos@debian.org> | no | 2022-09-26 | ||
0009-chap-Use-proper-entropy-source.patch | chap: Use proper entropy source The challenge sent to the initiator is based on a poor source of randomness, it uses rand() without seeding it by srand(). So the glibc PRNG is always seeded with 1 and as a consequence the sequence of challenges is always the same. An attacker which is able to monitor network traffic can apply a replay attack to bypass the CHAP authentication. All the attacker has to do is waiting for the server or the service to restart and replay with a previously record CHAP session which fits into the sequence. To overcome the issue, use getrandom() to query the kernel random number generator. Also always send a challenge of length CHAP_CHALLENGE_MAX, there is no benefit in sending a variable length challenge. |
Richard Weinberger <richard@nod.at> | no | debian | https://github.com/fujita/tgt/commit/abd8e0d987ab56013d360077202bf2aca20a42dd | 2024-09-03 |