I needed to create symlinks on alpha.gnu.org, and did not find the
accepted gnupload syntax in 'gnupload --help', Here is a proposed patch
to explain it.
2019-05-09 Bruno Haible
gnupload: Explain how to create symlinks.
* build-aux/gnupload (usage): Add an example that creates
Let me sync the gnulib module 'gettext' with the infrastructure from
gettext 0.20.
2019-05-09 Bruno Haible
gettext: Update to gettext 0.20.
* modules/gettext (Files): Remove m4/codeset.m4, m4/fcntl-o.m4,
m4/glibc2.m4, m4/glibc21.m4, m4/intdiv0.m4, m4/intl.m4, m4/intldi
On 5/9/19 3:13 PM, Bruno Haible wrote:
> So they are combining data flow analysis - in order to determine
> that the argument of base64_alloc is untrusted data - with a
> heuristic - "if a function contains array accesses with indices that
> are computed with ntohs calls, we should flag it as dange
On 5/8/19 11:39 PM, Florian Weimer wrote:
> atexit handlers run before ELF destructors (and some C++ destructors).
> There can also be multiple such handlers. So it's not true that an
> atexit handler always runs last.
OK, but this shouldn't be a problem with any applications currently
using clos
Hi Paul,
> Sorry, I'm still not following. Unless the tainted data is used to
> calculate an array index, there's no problem with Heartbleed and the
> Coverity heuristic should not diagnose a problem.
Yes, IF they were only using an algorithm and no heuristic,
base64_encode would not be flagged a
On 5/9/19 1:35 PM, Bruno Haible wrote:
>> https://www.synopsys.com/blogs/software-security/detecting-heartbleed-with-static-analysis/
>>
> base64_encode produces the
> warning because of the (x << n) | (y >> m) expression patterns that
> resemble a byte swap. It would do so also for any other progr
Hi Kamil,
> There are 3 important state-transitions in the data-flow analysis:
>
> (1) obtaining data from untrusted source
> (2) sanitizing the data (checking bounds etc.)
> (3) unsafe use of untrusted data
>
> gnulib's base64_encode() as seen by Coverity Analysis represents (3)
> because its i
On 5/7/19 7:22 AM, Kamil Dudka wrote:
> It triggered the following false positives in the cryptsetup project:
>
> Error: TAINTED_SCALAR:
> lib/luks2/luks2_digest_pbkdf2.c:117: tainted_data_argument: Calling function
> "crypt_random_get" taints argument "salt".
> lib/luks2/luks2_digest_pbkdf2.c:157
Hi Bruno,
On Wednesday, May 8, 2019 10:15:37 AM CEST Bruno Haible wrote:
> Hi Kamil,
>
> > Coverity Analysis 2019.03 incorrectly marks the input argument
> > of base64_encode(), and conseuqnetly base64_encode_alloc(), as
> > tainted_data_sink because it sees byte-level operations on the input.
>
C2X and C++17 finally added support for a simple, single-argument
‘static_assert’ that implements what the Gnulib ‘verify’ macro was
doing back in 2005. Implement static_assert on older platforms.
The only remaining advantage of ‘verify’ is a shorter name.
* doc/posix-headers/assert.texi (assert.h
* NEWS: Mention this.
* lib/verify.h (verify_true): Remove.
* tests/test-verify.c (item): Test verify_expr, not verify_true.
---
ChangeLog | 5 +
NEWS| 2 ++
lib/verify.h| 13 +++--
tests/test-verify.c | 2 +-
4 files changed, 11 insertions(+), 11 d
* lib/verify.h (_Static_assert): For the FreeBSD workaround,
use _GL_HAVE__STATIC_ASSERT, not _GL_HAVE_STATIC_ASSERT.
---
ChangeLog| 6 ++
lib/verify.h | 6 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 31e05adbd..12231d97b 100644
--- a/C
On 5/9/19 8:39 AM, Florian Weimer wrote:
> There can also be multiple such handlers. So it's not true that an
> atexit handler always runs last.
If a program is complex enough to have several atexit handlers
... then 'man atexit' applies:
"Functions so registered are called in the reverse orde
13 matches
Mail list logo
