[slf4j-user] Signatures for verifying Slf4j

Sat May 8 21:54:55 CEST 2010

From: slf4j-user-bounces at qos.ch [mailto:slf4j-user-bounces at qos.ch] On Behalf
Of Joern Huxhorn
Sent: Saturday, May 08, 2010 1:40 PM
To: User list for the slf4j project
Subject: Re: [slf4j-user] Signatures for verifying Slf4j

On 08.05.2010, at 20:08, Jeff Jensen wrote:

Great!  Glad the reply helped you and it works for you (hopefully Ceki will
do same :-). (note it is a Sonatype article, not mine!)

Ah, ok, I thought you wrote it and were one of them...

Regarding the plugin property names, yes it is a little misleading with the
short name given in the table (it's actually the property name in the Java
file).  The "Parameter Details" section lists the full property name
expression to use; hopefully you discovered that quickly!

Thanks for the gpg2 info.  I added a little doc note from your statements:

http://svn.apache.org/viewvc/maven/plugins/trunk/maven-gpg-plugin/src/main/j
ava/org/apache/maven/plugin/gpg/AbstractGpgMojo.java?view=diff
<http://svn.apache.org/viewvc/maven/plugins/trunk/maven-gpg-plugin/src/main/
java/org/apache/maven/plugin/gpg/AbstractGpgMojo.java?view=diff&r1=942420&r2
=908968&diff_format=u> &r1=942420&r2=908968&diff_format=u

Also, you shouldn't need the gpg plugin defined in <dependencyManagement> as
child modules can call profiles of parent.  I have only defined the gpg
plugin in the profile section.

It's actually not in dependencyManagement but in pluginManagement. I keep
all plugin versions there in an attempt of keeping some structure in the
file. This has the effect that I don't have to define a version at the place
I'm referring to the plugin but still have it well-defined at a specific
version.

I was fooled more than once by a failing build caused by a suddenly updated
plugin...

Ugh, not sure how I misread that!

Yes, excellent practice with pluginManagement.  I define the version in the
parent using a property for each version, and place the dependency in
plugin/dependency Management too.  The property approach is only one step
further to help with artifacts that use the same version number, e.g. a
bunch of the Spring ones, to ensure I upgrade correctly with only one
change.

Side note - I hadn't looked at Lilith for awhile as it didn't support direct
log file use.  Very happy to see ".to support writing of Lilith logfiles
using Logback FileAppender" added!  I will change the appender, try it, and
hopefully roll out Lilith for the team. (hmm, sidetracked looking for docs.)

Are you looking for Lilith docs? That's still somewhat lacking, I'm afraid.

Most of the documentation is contained in the help of Lilith itself at the
moment. Changing that is still on my agenda :p

Yeah, I scoured the websites looking for "doc" link.  I then looked at files
and found readme, but no config info.  Then wondered if docs were in the
dist, so downloaded and looked.  Then ran it and found the help menu J.
Nice easy example in there!  Thanks!  Very cool.  I have already added it as
a second appender (I think it would be good to have the human readable one
too; we'll see) and experimenting.

I hope you like it. Please let me know if you have suggestions.

Very cool - indeed I do (that's some fantastic searching and filtering).  I
tried using some Eclipse plugins for log files and haven't been satisfied
(actually, they are painful).  I can see Lilith becoming well used by us/my
future customers!  J  Very glad you added the Lilith appender.

My immediate thoughts are:

-        Add a note on the site stating where config info/doc is (the online
help file!).

-        Usability nit: restarting doesn't restore prior column widths;
can't double-click the line between column headers to auto-size.  Ah ha!
Just discovered save layout. nice!  (nevermind!)

-        Usability: A recent files list (we have at least 6 in different
locations, so would be easy way to open them after restart).  Possibly a
pref for reopen same files as when last ran?

-        Hmm, this would be great as an Eclipse view to have on same screen
(to replace using Console). :-D  But not necessary.  (oh, just noticed IDEA
one. must be what you use! ;-)

-        Adjust font size? (bottom detail pane is a bit small on my
1920x1200).

-        Do you deploy the Maven site anywhere?  You have good info and
reports configured (changes, etc.), would be good to publish it.  This could
be the easy way for you to solve issue #36 (create Lilith site)! J

Thanks again!

From: Joern Huxhorn [mailto:jhuxhorn at googlemail.com] 
Sent: Saturday, May 08, 2010 10:15 AM
To: User list for the slf4j project
Cc: Jeff Jensen
Subject: Re: [slf4j-user] Signatures for verifying Slf4j

Hi Jeff,

thank you very much for this information and your article! I wasn't aware of
this plugin.

I just changed my build process for Lilith accordingly.

See
http://github.com/huxi/lilith/commit/c2689ee57b263c6a2cb6241547a991703354bc6
f

I had to jump through some loops, though, since I have gpg2 instead of gpg:

The following two properties had to be added to my pom:

<gpg.useagent>true</gpg.useagent>

<gpg.keyname>740A1840</gpg.keyname>

The first one makes sure that gpg isn't complaining about an invalid option
(--no-use-agent was removed in gpg2) and doesn't ask for a passphrase
anymore.

This was quite tricky since the documentation of maven-gpg-plugin says that
it's called useAgent, which it isn't!

The second one selects the correct key used for the signature - which is a
good idea if you have more than one.

I wanted to comment on your article but, unfortunately, comments are
disabled.

Cheers,

Joern.

On 08.05.2010, at 03:23, Jeff Jensen wrote:

It is best if the artifacts are signed.  Sometime in the near future,
Central/Nexus will not accept artifacts without being signed.

This would prove the source for you more than the hashes.

Ceki: you should start signing the release artifacts.  It is very easy -
I've done it already on a few products and Sonatype has a very good page
describing how.  Maven will do it automatically for you:

http://www.sonatype.com/people/2010/01/how-to-generate-pgp-signatures-with-m
aven

From: slf4j-user-bounces at qos.ch [mailto:slf4j-user-bounces at qos.ch] On Behalf
Of Joern Huxhorn
Sent: Friday, May 07, 2010 3:50 AM
To: User list for the slf4j project
Subject: Re: [slf4j-user] Signatures for verifying Slf4j

One solution could be the use of signed tags for SLF4J and Logback.

That way it would be possible to pull the git repository, check the
signature of the tag and build SLF4J and Logback yourself afterwards.

I think the MD5 and SHA1 of Maven repository are merely a way to prevent
corrupted files, not an actual security feature.

Cheers,

Joern.

On 07.05.2010, at 09:26, Elisha Ebenezer wrote:

Hi Ceki,
I'm trying to push to use Slf4j and logback in our project and my company
wants me to get the MD5 or SHA1 hashes or the code-signing certs to verify
the integrity of downloaded files.

Though repo1.maven.org <http://repo1.maven.org/>  site provides the hashes,
we are not sure whether the war and the hash are uploaded by genuine party
or not.

As you are the owner of the project, I request you to kindly publish the
hashes or certs on website's download page.. which can be cross-checked with
the downloaded war and/or also with the maven repository.

Kindly do the needful and oblige.

Thanks,
Elisha Ebenezer. _______________________________________________
slf4j-user mailing list
slf4j-user at qos.ch
http://qos.ch/mailman/listinfo/slf4j-user

_______________________________________________
slf4j-user mailing list
slf4j-user at qos.ch
http://qos.ch/mailman/listinfo/slf4j-user

_______________________________________________
slf4j-user mailing list
slf4j-user at qos.ch
http://qos.ch/mailman/listinfo/slf4j-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-user/attachments/20100508/47762ff2/attachment-0001.html>