is the limit of ~9 hrs on caching your smime keyphrase due to mutt or openssl or something else?
if defined as such in mutt, then it would be relatively straightforward to change it to a unsigned 32-bit integer.
* bjarthur70@gmail.com, 2018-06-17 03:07 UTC:
if defined as such in mutt, then it would be relatively
straightforward to change it to a unsigned 32-bit integer.
I love it when someone not familiar with a code says "it would be
relatively straightforward" ...
browsing related source revealed
a) the timeout is added to a time_t, unsigned 32-bit couldn't be because
time_t may be signed 32-bit on some systems
b) suddenly the realms of possible overflows are entered
c) the options parser isn't prepared to handle 32-bit numbers (simply
all numeric options are short)
So, it's not just changing the type of a variable.
On Sun, 2018-06-17, Eike Rathke wrote:
browsing related source revealed
[...]
You're making it sound harder than it is.
c) the options parser isn't prepared to handle 32-bit numbers (simply
all numeric options are short)
Sounds odd; Unix software almost never uses short for stuff like that.
I haven't looked at the code (or at the use case) but IMO timeouts are
best supplied as hh:mm:ss, or some similar syntax which doesn't force
you to specify 9 hours as 32400. Would be nice to allow "9:00:00" or
"9h".
I'm tempted to submit a patch, but I don't use S/MIME myself.
I have a 'set pgp_timeout = 3600' line in my .muttrc though ...
So, it's not just changing the type of a variable.
Agreed. But it's pretty fair to expect that it /would/ be.
sorry, didn't mean to offend. by "relatively" i meant that openssl wouldn't need to be modified too.
as it stands now, smime in mutt is not useable for me. i'm simply not willing to type in my password every 9 hrs.
particularly if it's the case that if i mistype it, i have to completely quit out of mutt,
and then retype all my passwords in again, not just smime's.
c) the options parser isn't prepared to handle 32-bit numbers (simply
all numeric options are short)
Sounds odd; Unix software almost never uses short for stuff like that.
On 2018-06-18 06:57, Jorgen Grahn wrote:
c) the options parser isn't prepared to handle 32-bit numbers (simply
all numeric options are short)
Sounds odd; Unix software almost never uses short for stuff like that.
It isn't conventional to use unsgined types (of any size) for "stuff
like that" either. unsigned is for bit fields.
It isn't conventional to use unsgined types (of any size) for "stuff
like that" either. unsigned is for bit fields.
I was thinking plain int is the default type; I didn't mention
unsigned.
Are you mocking my choice of words, by the way?
On 2018-06-18 18:14, Jorgen Grahn wrote:
It isn't conventional to use unsgined types (of any size) for "stuff
like that" either. unsigned is for bit fields.
I was thinking plain int is the default type; I didn't mention
unsigned.
Right; my post was also a reaction to something upthread, which I should
have cited.
Are you mocking my choice of words, by the way?
No, I was tired and couldn't quickly come up with a better way to say
it. Even though I knew there was a better way, and that's why the quotes.
thanks for submitting the PR! hope you have time to make sure it is merged.
i still find mutt's handling of gpg passphrases better though: it simply doesn't store them if there is an error, and asks you to re-enter them.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 37:03:39 |
| Calls: | 6,648 |
| Calls today: | 3 |
| Files: | 12,193 |
| Messages: | 5,329,127 |