What is the point of this when we already have symcryptrun? https://gnupg.org/documentation/manuals/gnupg/symcryptrun.ht...
I don't understand how that link describes something that invalidates this?
A simple file encryption tool and format
11–20 of 29 posts
Re: A simple file encryption tool and format
#12I had another look at `age` a week or two ago to see what progress had been made, and I couldn’t find any code. I would be delighted to be able to ditch gpg...
Pretty sure at this point they’re just focused on getting feedback on the design before actually doing work on creating the tool. See this thread: https://twitter.com/filosottile/status/1180861642546073600?s...
Oh, that has become a lot more promising in the last couple of days :-)
Re: A simple file encryption tool and format
#13What is the point of this when we already have symcryptrun? https://gnupg.org/documentation/manuals/gnupg/symcryptrun.ht...
I don't understand how that link describes something that invalidates this?
Symcryptrun does more or less exactly what this document proposes to implement. It doesn’t invalidate it, it renders it unnecessary.
Re: A simple file encryption tool and format
#14>(...) it’s pronounced like the Japanese 上げ (with a hard g).
Now somebody just needs to write it in Rust or Haskell...
Re: A simple file encryption tool and format
#15>I know I am using signing keys for encryption, which is unholy. I’m sorry? Yawn.
Please don't do this here.
Re: A simple file encryption tool and format
#16Ugh, Go fails to parse RFC-3339 [0] correctly so our best hope for "Actually Good Encryption" will end up with badly formatted timestamps.
Timezone offsets should be represented by either a "+" (positive offset) for hours added to UTC in zones East of the prime meridian, or a "-" (negative offset) for zones to the West.
The Z suffix (meaning Zero hours offset from UTC, from the phonetic alphabet for "Zulu"), if it is used, should be the last character in a zero-offset (UTC) timestamp. However a UTC timestamp may instead be represented by a numeric offset of +00:00 hours.
The issue is that Go has, I believe misinterpreted the RFC and so presents the example timestamp:
2006-01-02T15:04:05Z07:00
In that example the "Z" should be a "-" as all the examples are set in the Mountain Standard Timezone. RFC-3339 is quite clear that numeric offsets should be prefixed by either a "+" or a "-", or that a "Z" may be used instead when there is no offset.
An issue [1] was raised on their Github, the first post of which explains the problem clearly, but somehow the replies got distracted with whether the colon in numerical offsets is optional or not, and was subsequently closed.
[0]: https://tools.ietf.org/html/rfc3339#section-5.6 [1]: https://github.com/golang/go/issues/31113
Re: A simple file encryption tool and format
#17Ugh, Go fails to parse RFC-3339 [0] correctly so our best hope for "Actually Good Encryption" will end up with badly formatted timestamps. Timezone offsets should be represented by either a "+" (positive offset) for hours added to UTC in zones East of the prime meridian, or a "-" (negative offset) for zones to the West. The Z suffix (meaning Zero hours offset from UTC, from the phonetic alphabet for "Zulu"), if it is…
Go has an unusual way of specifying date formats. The "example" timestamp is a format spec and I believe the 'Z' will correctly handle offset signs.
From the docs:
Replacing the sign in the format with a Z triggers the ISO 8601 behavior of printing Z instead of an offset for the UTC zone.
Re: A simple file encryption tool and format
#18Ugh, Go fails to parse RFC-3339 [0] correctly so our best hope for "Actually Good Encryption" will end up with badly formatted timestamps. Timezone offsets should be represented by either a "+" (positive offset) for hours added to UTC in zones East of the prime meridian, or a "-" (negative offset) for zones to the West. The Z suffix (meaning Zero hours offset from UTC, from the phonetic alphabet for "Zulu"), if it is…
[deleted]
Re: A simple file encryption tool and format
#19Ugh, Go fails to parse RFC-3339 [0] correctly so our best hope for "Actually Good Encryption" will end up with badly formatted timestamps. Timezone offsets should be represented by either a "+" (positive offset) for hours added to UTC in zones East of the prime meridian, or a "-" (negative offset) for zones to the West. The Z suffix (meaning Zero hours offset from UTC, from the phonetic alphabet for "Zulu"), if it is…
Go has an unusual way of specifying date formats. The "example" timestamp is a format spec and I believe the 'Z' will correctly handle offset signs. From the docs: Replacing the sign in the format with a Z triggers the ISO 8601 behavior of printing Z instead of an offset for the UTC zone.
There are several standards that specify how offsets should appear, but only Go uses Z (meaning Zero offset, aka UTC equivalent) followed by what appears to be a _positive_ number to represent a _negative_ offset...
By this logic we can expect to see a Moscow time stamp represented as HH:MM:SS+03:00 in every other program, and HH:MM:SSZ-03:00 only in Go.
It's just wrong, for no good reason.
Re: A simple file encryption tool and format
#20Earlier quoted context omitted.
Go has an unusual way of specifying date formats. The "example" timestamp is a format spec and I believe the 'Z' will correctly handle offset signs. From the docs: Replacing the sign in the format with a Z triggers the ISO 8601 behavior of printing Z instead of an offset for the UTC zone.
There are several standards that specify how offsets should appear, but only Go uses Z (meaning Zero offset, aka UTC equivalent) followed by what appears to be a _positive_ number to represent a _negative_ offset... By this logic we can expect to see a Moscow time stamp represented as HH:MM:SS+03:00 in every other program, and HH:MM:SSZ-03:00 only in Go. It's just wrong, for no good reason.
You are misunderstanding what you are seeing. The Z does not represent a literal Z in parsing/formatting.