• Stateless OpenPGP command-line interface for package management

    From Guillem Jover@21:1/5 to All on Thu Feb 6 13:50:01 2020
    Hi!

    Daniel Kahn Gillmor (CCed) has been working on a proposal for a
    stateless OpenPGP command-line interface (that would ideally eventually
    be supported by all OpenPGP implementations), both RFC draft and
    reference implementation, and we had a chat some time ago on what might
    be the requirements from a package manager PoV, where I mentioned I'd
    bring it up on the dpkg and apt lists. I've also CCed Peter Pentchev
    for debsigs. The draft can be found here:

    https://dkg.fifthhorseman.net/draft-openpgp-stateless-cli.html
    https://gitlab.com/dkg/openpgp-stateless-cli

    and the implementation (AFAIK) here:

    https://gitlab.com/dkg/python-sop


    I think that what we mostly need is:

    * verification support for:
    - multiple keyrings, mentioned explicitly as AFAIR there was talk
    about dropping this from GnuPG (?) (already supported).
    - inline signatures for .dsc, .changes, InRelease, etc
    (planned with something lile detach-inband-signature-and-message?).
    - unbundling inline signatures from their data, which could make it
    possible to remove the OpenPGP signature ASCII armored parsing
    code from dpkg-dev and apt, but this would come at the cost of
    having to depend on such implementation, which would increase
    the build-essential set. :/
    - being able to warn about or reject specific weak constructs,
    needed by apt, in the future by dpkg (not supported AFAICS).

    * querying support for:
    - getting the key ID matching a pattern in a keyring, needed by
    debsig-verify to match on its policy (not supported AFAICS).
    - getting the key ID used in a signature, needed by
    debsig-verify to match on its policy (not supported AFAICS),
    - getting the signature date (?), used by debsigs
    (not supported AFAICS, seems just informational use).

    * conversion support for:
    - binary to ASCII armored signatures, f.ex. for upstream tarball
    signatures (already supported).

    * signing support for:
    - specifying a key ID (not supported AFAICS?).


    These are off the top of my head, I might be missing more from apt's
    side though. But I think we'd all be very happy if we could stop
    having to parse --with-colons stuff, and having to deal with mixed
    metadata and data streamed out from GnuPG. :)

    Thanks,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Johannes Schauer@21:1/5 to All on Thu Feb 6 15:40:01 2020
    Hi,

    Quoting Guillem Jover (2020-02-06 13:45:46)
    Daniel Kahn Gillmor (CCed) has been working on a proposal for a stateless OpenPGP command-line interface (that would ideally eventually be supported by all OpenPGP implementations), both RFC draft and reference implementation, and we had a chat some time ago on what might be the requirements from a package manager PoV, where I mentioned I'd bring it up on the dpkg and apt lists.

    awesome! Thanks! :)

    I think that what we mostly need is:

    * verification support for:
    - multiple keyrings, mentioned explicitly as AFAIR there was talk
    about dropping this from GnuPG (?) (already supported).
    - inline signatures for .dsc, .changes, InRelease, etc
    (planned with something lile detach-inband-signature-and-message?).
    - unbundling inline signatures from their data, which could make it
    possible to remove the OpenPGP signature ASCII armored parsing
    code from dpkg-dev and apt, but this would come at the cost of
    having to depend on such implementation, which would increase
    the build-essential set. :/
    - being able to warn about or reject specific weak constructs,
    needed by apt, in the future by dpkg (not supported AFAICS).

    * querying support for:
    - getting the key ID matching a pattern in a keyring, needed by
    debsig-verify to match on its policy (not supported AFAICS).
    - getting the key ID used in a signature, needed by
    debsig-verify to match on its policy (not supported AFAICS),
    - getting the signature date (?), used by debsigs
    (not supported AFAICS, seems just informational use).

    * conversion support for:
    - binary to ASCII armored signatures, f.ex. for upstream tarball
    signatures (already supported).

    * signing support for:
    - specifying a key ID (not supported AFAICS?).


    These are off the top of my head, I might be missing more from apt's
    side though. But I think we'd all be very happy if we could stop
    having to parse --with-colons stuff, and having to deal with mixed metadata and data streamed out from GnuPG. :)

    mmdebstrap is also doing the --with-colons stuff parsing, so I'm very interested in this and wanted to add my two cents. What mmdebstrap basically needs is an answer to the question:

    "I have a keyring I know that I want to use (like
    /usr/share/keyrings/ubuntu-archive-keyring.gpg) -- is the key material from
    that keyring fully included in the keys trusted by apt?"

    Essentially I want to find out whether mmdebstrap should manually add the keyring I know is the right one to the ones apt should trust or whether that's not necessary because apt already trusts it.

    So far mmdebstrap is setting up a new gpg --homedir and parses gpg --with-colons to find out whether the fingerprints contained in the keyring I want are also found in the keyrings apt trusts.

    It would be nice if I would not need to setup a gpg home directory anymore and not need to parse --with-colons anymore. I assume the functionality I need is covered by the "querying support" part above?

    Thanks!

    cheers, josch

    --==============57451991834107579=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAl48IocACgkQ8sulx4+9 g+GxvA/+PMYpDeR95bWs0fE0IDT/v42G8yoOp4PuO6YNy6U3hZQigLdkOYhn+rlp /gyfWrWdOZ+668lMscFCrdh79L+9N5PM8Q9721Xb6+tqIWo5Dr5QiwPr1rt+O3SH uBUCrhiwSFJ8RuYb0nHj9lAbTMiYm+J3s95Rh5UzhJdRP/Eiam7I+SgiuY0p+HhW UoLA6TI3S4bdOM9C/Ppuzc80h6Xa4HMIKsbsvVh2l54wsvYEuKNXrKWovkA7Zp85 1U3DlniD94/H8hnnxhE+QyDLhbeR6Hn7n39iSK8+UKZEwuG+7YBlKPj6E+tDu7B2 LAH+jylBaa2P9ov6YdBxWNOjiAuG6Da8W+Xt2mZLzuh0BUQ8OE+Yw4bdkXjzhbKg zt3ypmSXJcb/Zh9HAaDKSiWCqsHxp0lMy7aCN8VrTRn5ZN13UyvBP7/+bMS/RDeP QGDWo6rawZPrHNuI+e5QajoKx1fkJ4CsVJ6G1vCMGpMON/1k5hS7uMyZFoSKZWKK HPlY7LfQiqKkRzyqncOqTJlv0SnpEU93GR1JTQ6YFJerafcsv8GcRuPyXQre1bIA 4d8n0sfDMkBezsUWNCHIwu3zjL0xdvhBZsdVt+y32SqlV0IBgp3iwF05In+QS7EP 8kHireYXmp9HmCp5hs0CogKZevp5K3TCsfOs2gOKIaRXavijaGg=
    =K/SE
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Kalnischkies@21:1/5 to Guillem Jover on Thu Feb 6 16:30:02 2020
    On Thu, Feb 06, 2020 at 01:45:46PM +0100, Guillem Jover wrote:
    Daniel Kahn Gillmor (CCed) has been working on a proposal for a
    stateless OpenPGP command-line interface (that would ideally eventually
    be supported by all OpenPGP implementations), both RFC draft and

    (a bit early for my long awaited birthday present, but I am not
    complaining – means I at least can stop thinking about going full NIH
    and further generalize apt wrapper(s) around gpg(v) and becoming (more)
    insane in the process…)


    I think that what we mostly need is:
    […]
    - inline signatures for .dsc, .changes, InRelease, etc
    (planned with something lile detach-inband-signature-and-message?).

    and of course detached (Release + Release.gpg) – apt internally splits InRelease into a Release and Release.gpg pair and hands this off to gpgv
    to have one less codepath.


    - unbundling inline signatures from their data, which could make it
    possible to remove the OpenPGP signature ASCII armored parsing
    code from dpkg-dev and apt, but this would come at the cost of
    having to depend on such implementation, which would increase
    the build-essential set. :/

    As apt would need that at runtime it is also a promotion to installed by default on every Debian system (with the assumption that apt is on every
    Debian system).

    We would probably need a non-python implementation for that.


    - being able to warn about or reject specific weak constructs,
    needed by apt, in the future by dpkg (not supported AFAICS).

    apt e.g. started to decline SHA1 well before upstream did. Every
    rejection should ideally have a --its-okay flag though as it is a bit
    sad that with every improvement we loose access to historic data.

    At the moment it is just too hard, but ideally I would like apt to have
    the option to say "I know its SHA1 and the key is expired, but download
    the data anyhow" without giving in and just disabling every check.


    * querying support for:
    - getting the key ID matching a pattern in a keyring, needed by
    debsig-verify to match on its policy (not supported AFAICS).
    - getting the key ID used in a signature, needed by
    debsig-verify to match on its policy (not supported AFAICS),

    apt would like to know the same for the whole Signed-By and related
    things (which does both by keyring file and by key fringerprint).
    apt would "just" need fingerprint instead of "key ID" here though.

    Sort of the reverse would be interesting to be able to drop apt-key
    for the more niece usecases of "which keys are included in keyring(s)"
    and "which keyring includes key with ID". As these queries tend to be
    done by users allowing more than just fingerprint would be good but
    hardly mission critical.


    * signing support for:
    - specifying a key ID (not supported AFAICS?).

    while apt itself doesn't use it, our tests do lots of signing. So
    signing with expired keys, weak hashes and stuff should ideally not be
    too hard. Convincing gnupg to do it is… fun.

    Proper support for clearsigning with multiple keys [0] might be helpful
    for ftpmasters/dak as that used to be one problem in providing InRelease
    for stable releases.

    [0] https://lists.gnupg.org/pipermail/gnupg-users/2013-July/047118.html


    Apart from ftpmasters/dak, I guess (c)debootstrap maintainers might be interested as well (as they sort-of reimplement apt they have the
    same big problem of "verifying Release" and with same (or worse)
    requirement of the least external dependencies possible).


    I fear though that we will find at least one user for every feature
    gnupg currently has, but wrapped in an interface which doesn't lend
    itself very well to automation and/or additional wrapping.
    So this could end up being a colossal undertaking…


    Best regards

    David Kalnischkies

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEE5sn+Q4uCja/tn0GrMRvlz3HQeIMFAl48LVMACgkQMRvlz3HQ eIOCeA//b68rozbisVRpa9oo14jlCaYWRxIuFwhauOWfuXCYud7LOg5YfkE8LkuE 6gYHZl/ukmhgptNxlQ2Iou+T57lc+7JPa5vyeWpTS9ffcnAYH2XW+UbmhyOyF2n/ FNCDq9mErIkf1H0Udfr7ep7RSxK6/BuyvjJiqN3mpobeXY08phZXNnL7Ug85ooFr MXby0iAwSAS2USMZ1tw48PeuBV/HzCT5eXv0ySwe6ztXAaSD1fV1o6t2oZUCDzt5 LXMfpJoj0+W5S5ab3E+bQFbPMoDSuoRkQwi0cRUFf3Bl1jvytCecBvZzewSEW8Sx yOlN6tKFC5ISGF/eJg1QZ2BoTAEigdA4t2HbJZ0cCZcEhcZA/jrtWzB60Kuz0GEz CbOMUlsWknKZrxfBaHmObismF1WFRP8ZUFAqquPw/3Jk08lyvZmE+s2W8yqmW0Cm mEUhgNliMedwuPSkrFL0vbhEfvhO/kNizgV2HZpLjgec+pin6IPmIPo66mDQbdAM CG8vztEpy2ux8ygL3mzqLHKcVxbSbqHa3UdXlz+SQf7Oh8wAMe3TQ4sPdcun1fKH RzDXthWHZyyHuFZYep7BBk/T9H/71yA0cyogYKIKo994Uq5/HYwHSzDyBntGS12y A1CigCAT/F4VR2o8jY+bjFDQewS2rqOEyswAGbVZLVFcDQDs0cs=
    =C6aS
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Kalnischkies@21:1/5 to Johannes Schauer on Thu Feb 6 16:50:01 2020
    On Thu, Feb 06, 2020 at 03:28:28PM +0100, Johannes Schauer wrote:
    "I have a keyring I know that I want to use (like
    /usr/share/keyrings/ubuntu-archive-keyring.gpg) -- is the key material from
    that keyring fully included in the keys trusted by apt?"

    That is a question though you should ideally ask apt instead of trying
    to peak inside its trusted keyrings and figure it out by yourself.
    Who knows what might change in the keyring setup in the future. [0]

    So if you can outline an interface I guess we can add it to apt-key
    to decouple mmdebstrap from this (I didn't mention your bootstrap
    specifically as I thought you were one of the lucky ones by delegate
    all these problems to apt).

    That said, I wonder why you are trying to answer that at all. Just place
    the keyring in apts trusted store for the bootstrap and remove it
    afterwards. Duplicated keys are no problem and the chroot hopefully ends
    up with the keyring package(s) it needs? (Anyway, different topic)


    Best regards

    David Kalnischkies

    [0] If I ever get back to https://salsa.debian.org/apt-team/apt/merge_requests/33
    the answer to which keyring is in the trusted set becomes a lot harder
    and/or undefined without additional knowledge. It is sorta-blocked by me realizing I would have to interact more with gpg(v) for this…

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEE5sn+Q4uCja/tn0GrMRvlz3HQeIMFAl48NBoACgkQMRvlz3HQ eINsBg/+P2fLg7gEq8CUlZ+Jdu2R5Rm0QRT+EjXOrgFYOV3+SP6mpwJwwNSZfVYU Ji2pNezlty85J/YpTJpcw2sz9WIDKiKUn3lKwgz+5Pp0zKdy9ofE08wGoaLB52jQ MEkVPrnERXd19M4bHv+TOF2oaCadCi3Z89XhcYRz2GeSoWQpGwbnzUZQknIJelDm OncSX+c3+umQS5L6LUpQzk9tXu2qYNBRCZnwPwDE156HukT1bO7H565rLjAy9ra8 0cYd8hj01h/vG9kEcoEcScf1zmr5Nt3kGTrUB2gnyODo/NsHDAxu/uG7Jmi4QG/4 w/FfvT++Aqcr2P+tIUAaFBEwH0Gu65yu8ygxmIh+VmemfVOiI04UQ8dyKEKNy30l ZBnicjIkB1+nPlKWo2a3FZZ+/y/rVNZXIht/C26U+jdhdXT9/x6M1+daRCOvzRZH fPoSdMnwxswcsdCbu7X/GHknq8hIQIUjeW2b+w196/AiGUwAOn02VOV2jq0iASDI dM7ESrBi5exN7bzG+nmvCL0Hl0YqLASTzxGA62Aw56IVUgEDxvKw4wAqF9gFGNYS jypgpkkY2X7PuQ7HxmSfnHpKUV6CPLO1JeWeN2c8NxyRjI+BHSeXk9kYB9ZboHw4 Kk63z11GomsR2rcoDmqk8kqLxJwpsS86FdwtMLtxLGLRJXSECNg=
    =+lQs
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Johannes Schauer@21:1/5 to All on Thu Feb 6 20:10:02 2020
    Hi,

    Quoting David Kalnischkies (2020-02-06 16:43:22)
    On Thu, Feb 06, 2020 at 03:28:28PM +0100, Johannes Schauer wrote:
    "I have a keyring I know that I want to use (like
    /usr/share/keyrings/ubuntu-archive-keyring.gpg) -- is the key material from
    that keyring fully included in the keys trusted by apt?"

    That is a question though you should ideally ask apt instead of trying
    to peak inside its trusted keyrings and figure it out by yourself.
    Who knows what might change in the keyring setup in the future. [0]

    So if you can outline an interface I guess we can add it to apt-key to decouple mmdebstrap from this

    I thought using apt-key was discouraged?

    The interface I need is very simple. I want to be able to give apt a keyring or a fingerprint and ask it: do you trust that one or not?

    I don't know whether I talked about that to you or julian via IRC but the conclusion was, that implementing it via calls to gpg and relying on /etc/apt/trusted.gpg(.d) was the right thing to do.

    (I didn't mention your bootstrap specifically as I thought you were one of the lucky ones by delegate all these problems to apt).

    Far from it. Today you already discovered how bloated mmdebstrap is. One reason is, that lots of stuff that could be in dpkg/apt actually is not. Dpkg recently made progress on changing this. My long term goal is to make mmdebstrap useless because apt offers something like "apt-get bootstrap" or the like.

    Thanks!

    cheers, josch

    --==============32784635503111780=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAl48YkEACgkQ8sulx4+9 g+FLQRAAgEvX1PBYIE9TIqdYFY68uJAMl/z286iK5lbZyQVNLoPLyPqajDEnzTdp 8GMPUjPIrM7w1rmxzTsBqS4vVHYrBgYj3iFwatgC2J3BOLqYtDCmUUCuFyfq3K5H pmEUyPtXnCI6JrI5dWohJcxE2xksFwFZPLUHtnkOXojwSU8uePGWyG1RMy0fFlxh B6szG8RPtlyBRHajSOI72w7nx2soAQWsxPuz0cI3U8ZQxzSRd/hdGbup/k/tC9m4 XVai+qbxd9ok7M6sBObtcTjbVBb6v3XuWBWTFh3J+oXVD3dXoBEJcJp1K2icgy2V Td698XKt/JqB5KkIAT9731Ik5DzaocZUEg6LnlbYCywQrMwz6Wkqt+iwpdMtZExm B/p7u6QxJGg9wHoxhp5MgtEY2Walf2eGaMAAfvbK1kLpjmpWk3YxotkE4ugNb2Gq FIObMWuj1bNf3vT4eVE1so2zFpGX5usQ+bNCczgdCrfQKfmhJr0xqlncuGYLxdJs Mv+8SyI6oga5Kx/o9DqEO5+ddDqGcyTb1OyBLfc7Y+0IAShyjl4kn6UsROSFrrF9 oLhbn4LsWT0jEO+IhlJEl5TWo+OULiKmZVlSjgT2UFrul4HF71VBlOpOdWB8qw6P 6pFjd06QMb+AvaRWLKvVKauUxV3oA6OCLwWEWVyo4ZCF6lqLXag=
    =IP94
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Kalnischkies@21:1/5 to Johannes Schauer on Fri Feb 7 02:30:01 2020
    On Thu, Feb 06, 2020 at 08:00:26PM +0100, Johannes Schauer wrote:
    Quoting David Kalnischkies (2020-02-06 16:43:22)
    On Thu, Feb 06, 2020 at 03:28:28PM +0100, Johannes Schauer wrote:
    "I have a keyring I know that I want to use (like
    /usr/share/keyrings/ubuntu-archive-keyring.gpg) -- is the key material from
    that keyring fully included in the keys trusted by apt?"

    That is a question though you should ideally ask apt instead of trying
    to peak inside its trusted keyrings and figure it out by yourself.
    Who knows what might change in the keyring setup in the future. [0]

    So if you can outline an interface I guess we can add it to apt-key to decouple mmdebstrap from this

    I thought using apt-key was discouraged?

    Yes and no. Most public uses currently are uses which we do not want to continue like "add" or "del" which require gnupg to be installed (which
    isn't guaranteed by apt) and "just" do something you can do by placing
    a file in a directory¹. Or things like abusing "adv" to receive or
    refresh keys from keyservers unchecked…

    It has many undocumented² uses though as it acts as our stateless gpg(v) command-line interface. There are also sensible questions a user might
    have like "list" and those aren't far away from your question.

    So yes, nearly everything apt-key does at the moment (in the public eye)
    will be gone at some point, but we will always need some tool which
    can be used to query the trusted set (as long as we have such a set).

    After all, I can reasonable define that /etc/apt/trusted.gpg.d/ will be supported in the following years to places files in as gpg/asc, but
    saying that this is the ONLY place and the ONLY file types you will ever encounter therein is a much larger interface I am not comfortable with.
    (As that prevents /usr/lib/apt/trusted.gpg.d/ as well as keybox support
    as we would need to coordinate such features with everyone then – both
    not planned ATM, but ruling out that we could have them (or others) at
    some point is painting us too much into a corner I think).


    ¹ We could provide wrapping commands for that, but a) the obvious names
    are already taken b) it will be ignored for at least two Debian releases
    as repo admins want something which works on every release – so I opted
    for the "compatibility" solutions as the only solution. Stuff like !33
    and Signed-By change this anyhow hopefully obsoleting the global trust
    store in the long run… Oh and c) no maintainer script needed in
    a keyring package which is always a good thing.

    ² Providing a stable API on top of gpg is hard if not impossible, so we
    keep that to ourselves. Sometimes it feels different to me, but apt just
    wants to be a package manager, not a general propose gpg wrapper…


    (I didn't mention your bootstrap specifically as I thought you were one of the lucky ones by delegate all these problems to apt).

    Far from it. Today you already discovered how bloated mmdebstrap is. One reason

    (For the avoidance of doubt by casual onlookers: That "discovery" was
    a joke on IRC based on another joke – not based on real facts.)


    is, that lots of stuff that could be in dpkg/apt actually is not. Dpkg recently

    Lets start with this one then as even something as simple as listing all fingerprints in all keyrings apt trusts has hidden gotchas with gpg
    (e.g. gpg used to hardcode [= haven't recheck recently] a limit of 40
    --keyring parameters and some apt users have A LOT of PPAs … #733028). apt-key has code for that and many other things already, you probably
    don't [or mmdebstrap is indeed very bloated and we should think about
    adding dist-upgrade to it to replace apt instead ;)].

    [And that is there this thread comes in: apt-key is more than 800 lines
    of shell madness to work around various things. And there are at least a thousand more lines in C++ – and the main think we are doing is checking
    if a file is correctly signed… how many lines should that really need…]

    Anyway, please open a (token) bugreport for this and mention if you want
    a "apt-key is-trusted" command and/or want me to give you a "apt-key
    adv" rune you can use with older apt versions. There are probably corner
    cases to consider (and optimizations like --readonly to be used), but
    something like the following could mostly work already.


    diff --git a/cmdline/apt-key.in b/cmdline/apt-key.in
    @@ -781,6 +781,16 @@ case "$command" in
    warn_on_script_usage
    foreach_keyring_do 'list_keys_in_keyring' --fingerprint "$@"
    ;;
    + is-trusted)
    + merge_all_trusted_keyrings_into_pubring
    + if [ "$#" = '0' -o "$(aptkey_execute "$GPG_SH" --keyring "${GPGHOMEDIR}/pubring.gpg" --with-colons --list-keys "$@" 2>/dev/null | grep -c '^pub:')" != "$#" ]; then
    + exit 1
    + fi
    + ;;
    + list-fingerprints)
    + setup_merged_keyring
    + aptkey_execute "$GPG" --with-colons --list-keys 2>/dev/null | grep '^fpr:' | cut -d':' -f 10
    + ;;
    export|exportall)
    warn_on_script_usage
    merge_all_trusted_keyrings_into_pubring


    (I guess list-fingerprints would actually be enough, but I think I could
    use both in the testcases – BUT I shouldn't think about/work on security related things that close to bed, so lets keep it at that for now and
    continue outside of this thread)


    Best regards

    David Kalnischkies

    P.S.: Likely my last message for this week [carnival sessions to run].

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEE5sn+Q4uCja/tn0GrMRvlz3HQeIMFAl48qV4ACgkQMRvlz3HQ eIMU1g//UE2qey8AmNY5qMFzI0r+8ExVDEdVPzLYKJllkYU+iLoWqD6Z3i72J2oQ p56mv3fXr+cAj7MvaOUYWICVEMqs/AIWdghbz6wFCzzH/YlbWIYh4evK4kFG72bO 0yW/UzQLnbiiq6lMN0l1SHDzcm+toIXwnxMDqvMYLqjq8/7soVE6+CZSTGApL8dj iJ6VdlcUvFW7nwZAqxiEz+1qYFZs8avSpMjkM0SbI8PTIzaEWGu52ZomD4RSnKSB oVZdHcky66iLKzodANFvSY1beBvJcrntXtioO0quJftZeKUsFs7ip2puojMJjnUm u9MXY/sKlgeDtA8BfA1KFJHW7PVAGRTpqeD393kXnTS7iquNuYh7He+px4fauQws f10b2saKUhxecRo9kQsR+o79l/Fk4iqIFgML16K+YsldubX+JS9/4rNeWCdmaGpt uJ/4V+gtYhduiGvbV9VPNMjnVV8Gp0AUlRi84EBxw5oZQuqZ7alY3EzCP6ZXkpnC 70iGLowmB29NqL+YvpmdZQFdT3LuVxY1xz2kQduzXFcmfQr9qlDttlMwM1T+YQya r8wHBGjQGkGvMuf4uqXmdHQJRyELbBPr2NOrnyUJnwskhbYVT2uDi0XZG6EjCwHF W49/ussVPwovktYOXYtMfwWaHFsGa75czwq7BYGgIS88pWYArHU=
    =WhGG
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)