path: root/dist-tools/shipper/rpm2lsm.1

.\"Generated by db2man.xsl. Don't modify this, modify the source.
.de Sh \" Subsection
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Ip \" List item
.br
.ie \\n(.$>=3 .ne \\$3
.el .ne 3
.IP "\\$1" \\$2
..
.TH "RPM2LSM" 1 "" "" ""
.SH NAME
rpm2lsm \- generate Linux Software Map entries from RPMs
.SH "SYNOPSIS"

.nf
\fBrpm2lsm\fR [-a \fIauthor\fR] [-k \fIkeywords\fR] [-p \fIplatforms\fR] [-m \fImaintainer\fR]
        \fIrpmfile\fR
.fi

.SH "DESCRIPTION"

.PP
This tool extracts tag information from an RPM file to generate a Linux Software Map (version 3) entry on standard output. Command-line switches support adding LSM fields that have no equivalents in RPMs. Here are the field-generation rules:

.TP
Title:
Taken straight from the RPM Name field.

.TP
Version:
Taken straight from the RPM Version field.

.TP
Entered-Date:
LSM-generation time in YYYY-MM-DD format.

.TP
Description:
Taken straight from the RPM Description field.

.TP
Keywords:
Taken from the value of the \fB-k\fR command-line option. If no such option is given, it is omitted.

.TP
Author:
Taken from the value of the \fB-a\fR command-line option. If no such option is given, it looks for an AUTHORS file in the current directory (GNU convention) and uses that. If no AUTHORS file is present, your email addess and full name from the password file

.TP
Maintained-By:
Taken from the value of the \fB-m\fR command-line option. If that was not given, taken from the RPM Packager field. If that was not given, fill in the Author name.

.TP
Primary-Site:
The first (site) line is taken from the RPM URL field. Second and subsequent lines list tarballs and RPMs that match on name, version number, and release number with the RPM algument. For each file, size in 1K blocks is filled in.

.TP
Alternate-Site:
This field is not generated.

.TP
Original-Site:
This field is not generated.

.TP
Platforms:
Taken from the value of the \fB-p\fR command-line option. If no such option is given, 'All' is filled in.

.TP
Copying-Policy:
Taken straight from the RPM License field.

.PP
These are all the fields supported in LSM version 3. You can see the : LSM template http://ibiblio.org/pub/Linux/LSM-TEMPLATE for full details.

.SH "AUTHOR"

.PP
Eric S. Raymond <esr@thyrsus.com>. For updates, see : http://www.catb.org/~esr/software.htmlhttp://www.catb.org/~esr/software.html.

.SH "SEE ALSO"

.PP
\fBrpm\fR(8).

class="p">>
        <LI>Previous message: <A HREF="000884.html">[fetchmail-devel] Bug#413059: --sslcheck - non-existent option	in the man page
</A></li>
        <LI>Next message: <A HREF="000889.html">[fetchmail-devel] Security vulnerability in APOP authentication
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#887">[ date ]</a>
              <a href="thread.html#887">[ thread ]</a>
              <a href="subject.html#887">[ subject ]</a>
              <a href="author.html#887">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>Hello,

I found a security vulnerability in the APOP authentication.  It is
related to recent collision attacks by Wang and al. against MD5.  The
basic idea is to craft a pair of message-ids that will collide in the
APOP hash if the password begins in a specified way.  So the attacker
would impersonate a POP server, and send these msg-id; the client will
return the hash, and the attacker can learn some password characters.

The msg-ids will be generated from a MD5 collision: if you have two
colliding messages for MD5 &quot;&lt;????@????&gt;x&quot; and &quot;&lt;&#191;&#191;&#191;&#191;@&#191;&#191;&#191;&#191;&gt;x&quot;, and the
message are of length two blocks, then you will use &quot;&lt;????@????&gt;&quot; and
&quot;&lt;&#191;&#191;&#191;&#191;@&#191;&#191;&#191;&#191;&gt;&quot; as msg-ids.  When the client computes MD5(msg-id||passwd)
with these two, it will collide if the first password character if 'x',
no matter what is next (since we are at a block boundary, and the end of
the password will be the same in the two hashs).  Therefore you can
learn the password characters one by one (actually you can only recover
three of them, due to the way MD5 collisions are computed).

This attack is really a practical one: it needs about an hour of
computation and a few hundred authentications from the client, and can
recover three password characters.  I tested it against fetchmail, and
it does work.

However, using the current techniques available to attack MD5, the
msg-ids sent by the server can easily be distinguished from genuine ones
as they will not respect the RFC specification.  In particular, they
will contain non-ASCII characters.  Therefore, as a security
countermeasure, I think fetchmail should reject msg-ids that does not
conform to the RFC.

The details of the attack and the new results against MD5 needed to
build it will be presented in the Fast Software Encryption conference on
March 28.  I can send you some more details if needed.

Meanwhile, feel free to alert any one that you believe is concerned.
I am already sending this mail to the maintainers of Thunderbird,
Evolution, fetchmail, and mutt.  KMail already seems to do enough checks
on the msg-id to avoid the attack.

Please CC me in any reply.

-- 
Ga&#235;tan LEURENT

</PRE>

<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	<LI>Previous message: <A HREF="000884.html">[fetchmail-devel] Bug#413059: --sslcheck - non-existent option	in the man page
</A></li>
	<LI>Next message: <A HREF="000889.html">[fetchmail-devel] Security vulnerability in APOP authentication
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#887">[ date ]</a>
              <a href="thread.html#887">[ thread ]</a>
              <a href="subject.html#887">[ subject ]</a>
              <a href="author.html#887">[ author ]</a>
         </LI>
       </UL>

<hr>
<a href="https://lists.berlios.de/mailman/listinfo/fetchmail-devel">More information about the fetchmail-devel
mailing list</a><br>
</body></html>