I can't be certain it's a false positive, I just assume so. Not sure how
clank is compiled and if I can produce the same bits to compare...
Take this email as you wish. Since NetBeans will include the same jars in
the next release it will get the same user feedback.
--emi
dum., 4 aug. 2019,
Hi,
Am Sonntag, den 04.08.2019, 13:52 +0300 schrieb Emilian Bold:
> The false positive
so the right thing to do is to tell the users, that their snake-oil
software is broken. I'm sure using clang/clank libraries in trojans is
realistic, these warnings are a sign of broken software (on the
This warning is for
53EDE27126390D0EF244777525FB7CCA13E34368-clank_0.3.9 too:
https://www.virustotal.com/gui/file/fd5846c6360095d6419bbbd0a89b41fcc4e799fad8a61a252dad28bd9b70f127/detection
and A1DC7BFEB1A7C4D6DBC9D74545C1686F14C229F8-clank_0.3.9 :
Well, since I mentioned I'd poked at writing a Java code signature hashing
tool, I figured why not finish it, so, if anyone's interested, here you
go. The readme explains what it does:
https://github.com/timboudreau/signature-hash
Wrote a few tests that pass (same hash with differently
+1 for milestones
-Sven
Christian Lenz schrieb am Fr., 2. Aug. 2019, 11:11:
> +1 for Milestones.
>
>
> Cheers
>
> Chris
>
>
>
> Von: Junichi Yamamoto
> Gesendet: Mittwoch, 24. Juli 2019 12:29
> An: dev@netbeans.apache.org
> Betreff: Re: Propose using milestones instead of labels
>
> I propose
On Sun, 4 Aug 2019, 09:08 Jan Lahoda, wrote:
> Because for non-release builds, it would be hard/impossible to find what
> sources were used to build the given module - it would even be misleading.
> And while that would typically be the "dev community", if the IDE log
> and/or About/Help are not
Hi,
Am Freitag, den 02.08.2019, 10:47 +0200 schrieb František Kučera:
> It would be nice if Netbeans use standard ssh-agent instead of
> configuring password or key in Netbeans.
netbeans can and does. I don't remember the last time I entered a
private key password into netbeans.
Greetings
> (Frankly, recording the source hash in the source distro feels like a
reasonable idea to me in any case - currently, if I see a source zip of
NetBeans, the only clue I have about the contents is the filename; that
feels very weak.)
Good point.
--emi
On Sun, Aug 4, 2019 at 11:08 AM Jan Lahoda
Hello,
These ZIP at
http://netbeans.osuosl.org/binaries/BBEBAEE8729CCF165E2080A915542C6875208F97-clank_0.3.9.zip
contains org-clang-sema.jar and org-clang-ast.jar which are flagged by
AVG and Avast as containing Java:Agent-CNL [Expl]:
*
On Sun, Aug 4, 2019 at 9:05 AM Neil C Smith wrote:
> On Sun, 4 Aug 2019, 07:06 Jan Lahoda, wrote:
>
> > So, for reproducible builds,
> > we need to solve the OpenIDE-Module-Build-Version attribute.
> >
>
> True. This is definitely only about the auto-generated attributes.
>
> It's not just
On Sun, 4 Aug 2019, 07:06 Jan Lahoda, wrote:
> So, for reproducible builds,
> we need to solve the OpenIDE-Module-Build-Version attribute.
>
True. This is definitely only about the auto-generated attributes.
It's not just about reproducible builds though, which we'd still have some
way to get
On Sun, Aug 4, 2019 at 8:37 AM Emilian Bold wrote:
> > For Apache
> releases, we could print the git hash into a file in the source distro, and
> read it from that file. Having the source hash in the source distro might
> be a good idea anyway.
>
> But then a release ZIP won't just be just a
> For Apache
releases, we could print the git hash into a file in the source distro, and
read it from that file. Having the source hash in the source distro might
be a good idea anyway.
But then a release ZIP won't just be just a checkout of a commit ID
but a generated ZIP file with other stuff
Hi,
Let me point out we have two manifest attributes:
OpenIDE-Module-Build-Version and OpenIDE-Module-Implementation-Version. The
Build-Version is the generated one, based on the date and git hash. If a
module specifies the impl. version, then both of these are generated, if
the module does not
14 matches
Mail list logo
