5 ms·

A simple file encryption tool and format

54 points by kmos 7y ago

fanf2 7y ago
I 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...
- landr0id 7y ago
  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=21 https://twitter.com/filosottile/status/1180861642546073600?s...
  - fanf2 7y ago
    Oh, that has become a lot more promising in the last couple of days :-)
- bertman 7y ago
  Here you go: https://github.com/FiloSottile/age https://github.com/FiloSottile/age
snek 7y ago
Could update link to age-tool.com.
- inetsee 7y ago
  I tried that link but got re-directed to the original Google Docs page. It sounds like a really interesting tool, but I haven't been able to find the actual code anywhere.
  - bertman 7y ago
    The repo: https://github.com/FiloSottile/age https://github.com/FiloSottile/age
bananocurrency 7y ago
>I know I am using signing keys for encryption, which is unholy. I’m sorry? Yawn.
- dang 7y ago
  Please don't do this here.
big_chungus 7y ago
Just so every one isn't confused, this is a spec only. It has not been written. I'm looking forward to seeing what comes out of it, but it has been a spec for a while and no progress yet, so don't be surprised when you can't find the github. That said, I think it's excellent that they guys behind this are taking the time to think it out and design it well before they start slinging code. I believe a much better end result will be achieved because of it.
deleted 7y ago
[deleted]
danielparks 7y ago
Please please please use standard command line flag format (getopt_long) instead of the Go’s flag format. It’s super irritating that Go programs do it their own, less convenient way. For example: https://github.com/DavidGamba/go-getoptions https://github.com/DavidGamba/go-getoptions
- snailmailman 7y ago
  I’m not sure I understand, what’s the difference? I’ve never had any problems using go programs’ command line flags myself.
  - oarsinsync 7y ago
    I believe GP's remarks are that single hyphen followed by letters should each be individual flags, and double hyphen followed letters is a single flag in long form. The application in question is using -generate rather than --generate.
  - danielparks 7y ago
    oarsinsync is correct. The standard on most UNIX-like OSes is that long options, e.g. --long, have two dashes, and short options, e.g. -l, have one. It allows you to combine multiple options into one. For example, the following two commands are equivalent: $ ls -laF $ ls -l -a -F
teddyh 7y ago
What is the point of this when we already have symcryptrun? https://gnupg.org/documentation/manuals/gnupg/symcryptrun.html#symcryptrun https://gnupg.org/documentation/manuals/gnupg/symcryptrun.ht...
- detaro 7y ago
  I don't understand how that link describes something that invalidates this?
  - teddyh 7y ago
    Symcryptrun does more or less exactly what this document proposes to implement. It doesn’t invalidate it, it renders it unnecessary.
nothingnewhere 7y ago
>(...) it’s pronounced like the Japanese 上げ (with a hard g). Now somebody just needs to write it in Rust or Haskell...
lozf 7y ago
Ugh, 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 which has a Z (meaning UTC), and then an ambiguous offset from it. 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 https://tools.ietf.org/html/rfc3339#section-5.6 [1]: https://github.com/golang/go/issues/31113 https://github.com/golang/go/issues/31113
- lann 7y ago
  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.
  - lozf 7y ago
    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.
    - 7y ago
bertman 7y ago
Because there's no link to the source code in the google document, here's the Github repo: https://github.com/FiloSottile/age/ https://github.com/FiloSottile/age/

54 points by kmos 7y ago

I 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...

landr0id 7y ago
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=21 https://twitter.com/filosottile/status/1180861642546073600?s...
- fanf2 7y ago
  Oh, that has become a lot more promising in the last couple of days :-)
bertman 7y ago
Here you go: https://github.com/FiloSottile/age https://github.com/FiloSottile/age

snek 7y ago

Could update link to age-tool.com.

inetsee 7y ago
I tried that link but got re-directed to the original Google Docs page. It sounds like a really interesting tool, but I haven't been able to find the actual code anywhere.
- bertman 7y ago
  The repo: https://github.com/FiloSottile/age https://github.com/FiloSottile/age

bananocurrency 7y ago

>I know I am using signing keys for encryption, which is unholy. I’m sorry? Yawn.

dang 7y ago
Please don't do this here.

big_chungus 7y ago

Just so every one isn't confused, this is a spec only. It has not been written. I'm looking forward to seeing what comes out of it, but it has been a spec for a while and no progress yet, so don't be surprised when you can't find the github. That said, I think it's excellent that they guys behind this are taking the time to think it out and design it well before they start slinging code. I believe a much better end result will be achieved because of it.

deleted 7y ago

[deleted]

danielparks 7y ago

Please please please use standard command line flag format (getopt_long) instead of the Go’s flag format. It’s super irritating that Go programs do it their own, less convenient way. For example: https://github.com/DavidGamba/go-getoptions https://github.com/DavidGamba/go-getoptions

snailmailman 7y ago
I’m not sure I understand, what’s the difference? I’ve never had any problems using go programs’ command line flags myself.
- oarsinsync 7y ago
  I believe GP's remarks are that single hyphen followed by letters should each be individual flags, and double hyphen followed letters is a single flag in long form. The application in question is using -generate rather than --generate.
- danielparks 7y ago
  oarsinsync is correct. The standard on most UNIX-like OSes is that long options, e.g. --long, have two dashes, and short options, e.g. -l, have one. It allows you to combine multiple options into one. For example, the following two commands are equivalent: $ ls -laF $ ls -l -a -F

teddyh 7y ago

What is the point of this when we already have symcryptrun? https://gnupg.org/documentation/manuals/gnupg/symcryptrun.html#symcryptrun https://gnupg.org/documentation/manuals/gnupg/symcryptrun.ht...

detaro 7y ago
I don't understand how that link describes something that invalidates this?
- teddyh 7y ago
  Symcryptrun does more or less exactly what this document proposes to implement. It doesn’t invalidate it, it renders it unnecessary.

nothingnewhere 7y ago

>(...) it’s pronounced like the Japanese 上げ (with a hard g). Now somebody just needs to write it in Rust or Haskell...

lozf 7y ago

Ugh, 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 which has a Z (meaning UTC), and then an ambiguous offset from it. 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 https://tools.ietf.org/html/rfc3339#section-5.6 [1]: https://github.com/golang/go/issues/31113 https://github.com/golang/go/issues/31113

lann 7y ago
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.
- lozf 7y ago
  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.
  - 7y ago

bertman 7y ago

Because there's no link to the source code in the google document, here's the Github repo: https://github.com/FiloSottile/age/ https://github.com/FiloSottile/age/