KAstrometry is an astrometry program for KDE. It is written in Python. It aims to be a good tool to make measurements of objects in space from images taken by CCD cameras. Such measurements might be used to find orbits of astroids or record the brightness of variable stars. One day, it should be able to record an object's position, detect stars, and find coordinates using star catalogs.
AstroBuffer is a CCD astrophotography image manipulation application. It can open FITS and SBIG (st9) files. Contrast is adjustable to view different backgrounds and ranges of an image. It can scale, shift, rotate, and zoom in and out. Images can be aligned based on two star alignment, and can be summed, subtracted, averaged, and divided. RGB color images can be created from three images. Images can be saved as FITS or as any format that QT supports.
> If not this is still very cool and a lot
> better than the typical user-password
> scheme. This could be a good way to
> prevent those scam 'paypal', 'ebay'
> emails from working. Even if the
> scammers receive valid signed requests,
> to prevent abuse websites just need to
> have the request include a shared random
> seed parameter.
Actually after I submitted the comment I realized, to prevent the scams we need more than just a shared random seed. I believe the plugin would also have to send some parameter always like some dummy parameter (such as the full actual url) that can't be overriden. As just a shared random seed can still be vulnerable to the scams, because the random seed request could just be relayed through the scammers site to the client. Random seed parameters would prevent abuse at a later time though when the user is not currently using the scam site.
I don't know if scam prevention was part of your goals. I did read in your comments you originally sent this idea to Goggle so maybe it was. I believe there is still much to think of with such a scheme to make it secure.
> % Also I wonder, why can't you keep the
> % pass phrase in memory only instead of
> % writing to a temp file?
> Hi! Thanks for your comments. Enigform
> 0.8.0 supports gpg-agent. When the Agent
> is not used, passphrase is sent to a
> temp file on a random directory under
> the OS's native temp dir each time a
> signed request is sent. Then, with gpg's
> --passphrase-file parameter, it is read.
> After it is sent, the file and
> directories are deleted. Passphrase is
> kept in memory if user chooses to.
> Maybe I do not understand your question
> I'd love to use --passphrase-fd, but I
> Component, because I'd be limiting to
> the platforms JSIPC supports. I might
> end up doing that for 1.0.0, and
> fallback to the current methodology on
> unsupported OSes.
Yeah, I think you understand correctly.
You'll have to forgive me as I haven't written any addon's for Firefox or Thunderbird. I was looking through Enigmail and Enigform source to try to see the difference in the handling of the passphrase. I may be mistaken but it looks like Enigmail never writes the passphrase to file.
Even though the passphrase is deleted soon after, since it is written to disk it is possible yet unlikely to recover it from the disk in case it was stolen or something.
In any case it isn't a big deal, I shouldn't have brought it up. Keep up the good work.
From my previous post, you can see I'm much interested to see this as a possible replacement for SSL. Reading from your other documents it seems your main goal is client-server authentication though gpg and the server-client communication can be done through regular SSL. Is it part of your future goals to have the server-client communication work in a similar way as you have the client-server stuff going on now?
If not this is still very cool and a lot better than the typical user-password scheme. This could be a good way to prevent those scam 'paypal', 'ebay' emails from working. Even if the scammers receive valid signed requests, to prevent abuse websites just need to have the request include a shared random seed parameter.