topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Thursday March 28, 2024, 5:40 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - bastik [ switch to compact view ]

Pages: [1]
1
Finished Programs / SOVLED: Checking .asc files with GUI
« on: February 27, 2012, 12:16 PM »
Problem: Checking .asc files under windows is painful.

There's certainly a need for it.

Background: Some developers sign theier software with PGP or GPG.
GPG is a command line tool and there fore requires some typing.

Normal work flow:
- Download software and signature file. (Lets asume to C:\Download)
- Open CMD
- type "C:\Program Files\Gnu\GnuPg\gpg.exe --verify C:\Download\Installer.exe.asc C:\Download\Installer.exe (note it's C:\Program Files (x86) for 64bit systems)

Technical background:
- gpg.exe require the public key of the signer
- gpg.exe checks the checksum of installer.exe and the signature, both have to be vaild
- gpg.exe returns:

gpg: Signature made TTT MMM YYYY hh:mm:ss AM/PM EDT using RSA key ID [ID]
gpg: Good signature from "[Name] <[email]>"
gpg:                 aka "[Name] <[email]>" {if any, can be more than one}
gpg: WARNING: This key is not certified with a trusted signature! {whenever it's a known key, but no trust level is set}
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: HXHX HXKX HXHX HXHX HXHX  HXHX HXHX HXHX HXHX HXHX {hex fingerprint}
when everything is OK.

A tool should make this easier.

The tool should allow selection of an .asc file (one at a time seems to be OK) and the corresponding  signed download (can be anything, and maybe is not named) and pass those information to gpg.exe and return the results to the user. It's a GUI for gpg.exe, I think. Well not a fully GUI, just for the verification function. The tool just passes everything to gpg.exe and does not do any cryptographically related work.

Requirements:
- Allow path selection for singature file (.asc)
- Allow path selection for signed file
- Return the results

Optional:
- Allow selection of the path where gpg.exe is installed
- Interpret the results and give user-friendly feedback*
- portable
- or a shell extension (right click menu)
- Whenever the tools parses/interprets the results it would be cool when it could remember the ID and the fingerprint and warn when both don't match on the next check.

* E.g.
"[Signed file] was signed at TT MM YYYY hh:mm:ss AM/PM with key [ID] by [Name] [email]! The signature is vaild! Key Fingerprint: [HXHX .....]. Details"
Where details is a button or link, that shows the full results.

"The key [ID] is not know." or "The key [ID] is not in your keyring. Please add it to your keyring." Whenever the public key of the signer is not know to gpg.exe

2
General Software Discussion / Searching inside of Open Document files?
« on: February 27, 2012, 12:08 PM »
Problem: Searching inside of Open Document files.

Goal: Search through .odt-files, specified by the user and look for string(s) specified by the  user and list matching ones.

Does anybody know a tool that's capable of doing that? (o3find, worked but only with old binary files)
In the case it does not exist (at least I was not able to find something useful) I included information, so one might be able to code something.

Don't treat it as request!

Requirements:
- Ability to search through Open Document Text files (.odt)
- Handle multiple files at once

Optional:
- Support all Open Document Files
- Support M$ Documents, txt files
- Portable
- Support RegEx
- be an plugin for FARR
- Tell the user which files are encrypted and therefor could not be searched

Background:
Open Document files are zipped and therefore ignored. The tool therefor needs to unpack the files and be able to read the contents of the content.xml

I don't think it has to parse the XML.

3
Some users describe a slow display of results and/or an hanging of FARR when they start searching. Especially with just two characters.  To work around it FARR could be extended with an option to start looking for results after a certain amount of characters have been entered.

Example: Start search after 3 entered characters. (Where three can be changed by the user)
"Fi" won't return any result
"Fir" would return "Firefox, Firewall, Firmware, etc)

This reduces the disk access and maybe the load on CPU and memory.

As exception to setting it could be treated as default or set by the user:
- Unless it's an modifier or an alias (so +DC would still return something)

Pages: [1]