On 5/10/19 4:32 AM, Kamil Dudka wrote:
I do not think it is a good idea to change a piece of working code to make
a static analysis false positives magically disappear.
I was thinking of making a change only if it makes the code a bit better
even ignoring whether Coverity is used. Surely we
Thanks, this looks good to me.
Hi,
I'm using git-version-gen in GNU gettext. For the 0.20 release, I
created an empty commit, like this:
CURRENT_VERSION=0.20
git commit --allow-empty -m "Release $CURRENT_VERSION"
git tag v$CURRENT_VERSION
Now, git-version-gen ignores this release commit:
$ git describe
On Friday, May 10, 2019 4:11:45 PM CEST Bruno Haible wrote:
> Kamil Dudka wrote:
> > Thanks! This also helps to suppress the false positives on cryptsetup
> > with Coverity Static Analysis version 2019.03.
>
> Good! Since this is the approach that Paul prefers, I'm pushing this one:
>
>
>
Kamil Dudka wrote:
> Thanks! This also helps to suppress the false positives on cryptsetup
> with Coverity Static Analysis version 2019.03.
Good! Since this is the approach that Paul prefers, I'm pushing this one:
2019-05-10 Bruno Haible
base64: Avoid false positive warning from
On Friday, May 10, 2019 12:13:32 AM CEST Bruno Haible wrote:
> 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
On Friday, May 10, 2019 1:34:55 PM CEST Florian Weimer wrote:
> * Kamil Dudka:
> >> For example, how do you know that the reports are false positives and not
> >> true positives?
> >
> > I think it was obvious from my previous explanation:
> >
> > (1) You need to check (by manual review) that
On Thursday, May 9, 2019 10:35:18 PM CEST Bruno Haible wrote:
> 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
> >
> >
* Kamil Dudka:
>> For example, how do you know that the reports are false positives and not
>> true positives?
>
> I think it was obvious from my previous explanation:
>
> (1) You need to check (by manual review) that the source of data is really
> untrusted.
>
> (2) You need to check (by manual
On Thursday, May 9, 2019 9:14:40 PM CEST Paul Eggert wrote:
> 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
* Kamil Dudka:
> On Friday, May 10, 2019 12:17:11 AM CEST Paul Eggert wrote:
>> 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
On Friday, May 10, 2019 12:17:11 AM CEST Paul Eggert wrote:
> 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,
12 matches
Mail list logo
