Custom Repo - gpg signing

Help
Anonymous
2012-03-20
2013-06-05
  • Anonymous - 2012-03-20

    Having a few issues getting gpg signing to work on a custom repo.

    My versions.xml and apps.xml each have tags for signatures and pubkeys

        <signature>http://192.168.10.66/appupdater/fuerte-x86-apps.xml.asc</signature>
        <pubkey>http://192.168.10.66/appupdater/winros.fuerte.pub.asc</pubkey>
    
        <signature>http://192.168.10.66/appupdater/fuerte-x86-versions.xml.asc</signature>
        <pubkey>http://192.168.10.66/appupdater/winros.fuerte.pub.asc</pubkey>
    

    The signatures are detached sigs generated by gpg on an ubuntu lucid server with a key that has ascii export of the key winros.fuerte.pub.asc. I also sent the key to public gpg servers (though I don't think this is actually necessary?).

    On the windows appupdater side though, I'm getting fails in signing in:

    Using config at C:\ProgramData\Appupdater\appupdater.ini.
    WARNING: GPG Check FAILED for C:\ProgramData\Appupdater\230e0805ac3a13699cecc402bf8a53a512113d7a\fuerte-x86-apps.xml. Not using!
    

    I haven't done gpg signing before so I may have missed something in the process. Is there anything obvious you might add or is there an easy way to debug the python code for more info on the windows appupdater side?

     
  • nabber00

    nabber00 - 2012-03-20

    It could be a few things, in order of likelihood:

    1. Appupdater doesn't actually have your key in the keystore.  Drop the .asc file into %PROGRAMFILES%\Appupdater\keys and it should grab it next time it starts.
    2. You don't have the auto-import from repository option enabled.  I guess this option can be misleading, I believe I implemented it only to accept to new keys from repositories where the signature is valid for security reasons.  The purpose is to distribute new keys when the existing one is due to expire soon, not distribute new keys.
    3. The signature is actually failing.  You can run GPG directly to find out why.  Be sure to specify the Appupdater keystore, C:\Documents and Settings\All Users\Application Data\Appupdater\appupdater.gpg on Windows XP.

    Feel free to let me know if I can help, I'm always interested in feedback on the repository system as there aren't too many people I know of using it.

     
  • Daniel Stonier

    Daniel Stonier - 2012-03-22

    1. Dropped it into the keys subdirectory, but also noticed appupdater was depositing the ascii key automatically in C:\ProgramData\Appupdater\07104894cd07495d843a0413de10c267a188. So that shouldn't be an issue.

    2. I have the option enabled. Bit confused to your meaning - you say it is not for distributing new keys. So how would it get a new key? How does it get the Nabber keys?

    3. I can import my .asc key into the default ring and manually verify the signatures of my custom apps.xml and apps.xml.asc files, but as far as I can tell, my .asc key is not getting imoprted into the appupdater keyring.

    App updater's key store:

    C:\ProgramData\Appupdater\appupdater.gpg
    ----------------------------------------
    pub   1024D/D9615E8F 2005-09-29
    uid                  Neil C McNab <mcnab@nabber.org>
    sub   2048g/121C44CA 2005-09-29
    pub   1024D/375622F8 2007-07-25 [expired: 2009-12-31]
    uid                  Nabber.org <webmaster@nabber.org>
    pub   1024D/50776145 2009-09-24 [expired: 2011-01-01]
    uid                  Nabber.org <webmaster@nabber.org>
    pub   1024D/C9BBF4E7 2010-11-06 [expired: 2012-01-01]
    uid                  Nabber.org <webmaster@nabber.org>
    pub   4096R/2DF1479E 2011-07-16 [expires: 2013-01-06]
    uid                  Nabber.org (2012) <webmaster@nabber.org>
    sub   4096R/B993EE72 2011-07-16 [expires: 2013-01-06]
    

    App updater's repo xml's and signatures:

    Directory of C:\ProgramData\Appupdater\d58686ab9dbf8e156cb0f0b206be763854bb0a40
    22/03/2012  09:40 AM    <DIR>          .
    22/03/2012  09:40 AM    <DIR>          ..
    22/03/2012  09:40 AM             4,098 fuerte-x86-apps.xml
    22/03/2012  09:40 AM               490 fuerte-x86-apps.xml.asc
    22/03/2012  09:40 AM               716 fuerte-x86.metalink
    

    My key (downloaded by appupdater):

     Directory of C:\ProgramData\Appupdater\205eecef59fac4544f58c7ff20c7e82395416004
    22/03/2012  09:40 AM    <DIR>          .
    22/03/2012  09:40 AM    <DIR>          ..
    22/03/2012  09:40 AM    <DIR>          winros.fuerte.pub.asc
    
     
  • Daniel Stonier

    Daniel Stonier - 2012-03-22

    Also noticed that running gpg anywhere except from gpg's home directory results in an error:

    C:\work>gpg
    gpg: error loading `iconv.dll': The specified module could not be found.
    gpg: please see http://www.gnupg.org/download/iconv.html for more information
    gpg: Go ahead and type your message ...
    

    Not sure if that is relevant or not.

     
  • nabber00

    nabber00 - 2012-03-22

    Have you tried it again since dropping the key into the "keys" folder?  That is the ONLY way to get Appupdater to recognize a brand new key and add it to appupdater.gpg.  In other words, a key that hasn't been signed by another key in the "keys" directory.  Appupdater will of course download repositories and keys to the temporary folder, but it won't actually do anything with them unless the signature check passes.  The Nabber.org keys are distributed with the program and are dropped into the "keys" directory at install.

    The GPG error you reference doesn't seem to be a problem based on the URL.  Its possible Appupdater isn't parsing the output correctly, but I don't think that is the case.  Appupdater runs GPG with "-status-fd 2" so you can see if you still get that error in that mode.

     
  • Daniel Stonier

    Daniel Stonier - 2012-03-25

    Oh indeed. It's picked it up now. I'll do a clean install tonight and verify exactly that it was dropping the key into 'keys' and restarting.

    Rewinding a little - were you saying above that the auto-import from repository option didn't actually import a new key? Just updated expired keys? If so, what is the preferred way for a user to get keys? Getting a user to manually download and copy the key to the keys folder is probably beyond what most users would do.

    Also, if security mode is on, but the app/version xml's didn't specify a signature or pubkey tag, it would be convenient if appupdater didn't reject them. That way you could have secure and non-secure repos side by side and also users wouldn't really ever have to worry about changing the security options.

     
  • nabber00

    nabber00 - 2012-03-26

    The preferred way for a user to get keys is by distributing it with the application.  I will gladly include keys for any public repository.  I would expect that any private use would have its own methods of getting the keys to users.  This could be either a custom version of the installer or simply putting the key in proper directory via some automated means or manual instructions or something else.

    Appupdater is secure by default.  The idea is that a user SHOULD have to worry if they are they going to be in a non-secure mode and make a conscious decision if they wish to do so.  Given the capability that Appupdater has to install applications at will, I believe this is the only responsible default.  Linux updates work in a similar manner.

    If those answers aren't working for you if you can describe your use case perhaps I can help devise a sufficient solution for your needs.

     
  • Daniel Stonier

    Daniel Stonier - 2012-03-28

    I've got no problems with something being secure by default. What I was suggesting isn't invalidating this, but just providing a practical way to have 'secure' repositories and 'non-secure' repositories working side by side.

    If you want an example - ubuntu does this. I have a private ubuntu .deb repository on our company's lan server to serve our robot control packages. This doesn't need to be secure, and so isn't worth the development cost and effort in making it secure. As a result, it's been quickly/simply setup using dpkg-scanpackages with no signatures or public keys.

    Synaptic (equivalently apt-get underneath the hood) permits it to run alongside the secure official repositories. It would be impractical to either have to turn off all the official repos when wanting to use our own repos, or insecure to use those official repos while also working with our private repo in insecure mode.

    This would be a feature I'd like to see in appupdater - when appupdater is in secure mode, let the repo decide on whether appupdater should do signing simply by checking whether the repo supplies signatures/public keys. You could provide a warning if you like, whenever re-downloading repo information.

     
  • Daniel Stonier

    Daniel Stonier - 2012-03-28

    Checking whether the repo supplies signatures/public keys -> easily determined by the presence of signature and pubkey tags in the xml's.

     
  • nabber00

    nabber00 - 2012-03-28

    What I was suggesting isn't invalidating this, but just providing a practical way to have 'secure' repositories and 'non-secure' repositories working side by side.

    I believe what you are asking for already exists.  Set the security setting to "Request" instead of "Require" and this will allow both types to exist simultaneously.

     
  • Daniel Stonier

    Daniel Stonier - 2012-03-29

    Oh, indeed - sorry I missed it. 'Request' wasn't obvious - I'd assumed it was interactive.

    Would this not be a reasonable default?

     

Log in to post a comment.