[csw-maintainers] ideas

[Maciej Bliziński]

2011/7/13 Ben Walton <bwalton at opencsw.org>:
> Excerpts from Maciej Bliziński's message of Mon Jul 11 05:55:36 -0400 2011:
>> 2011/7/11 Ben Walton <bwalton at opencsw.org>:
>> > I misinterpreted what you meant here.  Yes, a cron job on the private
>> > host running as the same uid as the daemon could sign some file and
>> > verify it.  If this fails, mail would be sent.
>>
>> Yup, that's the idea I had.
>
> Ok, here's what I've got:
>
> 1. A screen session gets started with two screens.  One screen runs
>   the signing daemon and the other a verification script.
> 2. The signing daemon creates a gpg-agent process and saves the info
>   for use by other programs.  It then runs the restful web agent.

Sharing of the gpg-agent is on the user level, so being able to run as
the same user on the same host lets you access the key, is that
correct?

> 3. The verification script tries to encrypt the signing daemon script
>   every minute.  If it fails, it will generate an alert and wait for
>   operator intervention.

How does the verification script reach the signing daemon?

> 4. Operator intervention will take the form of a script that connects
>   to the verification screen to accept the passphrase again.
>
> Until the passphrase times out, you can test the restful interface by
> hitting:
>
> http://unstable9x:9981/clearsign/current/i386/5.10
>
> detachsign is also an option as is unstable in place of current.

I need more instructions (URLs?). The best I could do so far, was:

maciej at login [login]:~/src/opencsw-git/gar/v2 > curl -s
http://unstable9x.bo.opencsw.org:9981/clearsign/current/i386/5.10
500 There was a problem processing the request.

> If this is run on a private host where all gpg files reside on
> host-local storage and the mirror tree is shared to this host so it
> can see the catalog files to sign, we should be in reasonable shape as
> long as we trust the nfs share...

Looks good enough for now.  In the target setup, the verification
daemon will also verify signatures of individual packages, so trusting
the NFS share will not be necessary.

> We'd need to make the signing agent sign catalog.update or catalog.new
> or something instead of catalog as presumably catalog would be the
> previously clear signed file.  (I'm still happy to see clear signed
> catalogs go away in favour of a detached signature.)

+1

> I still have some error handling and logging to take care of, but I
> think the proof of concept is in good shape now.
>
> Thoughts?

Sounds great!  Can you show an example of the signing daemon usage?

Maciej