
A simple file encryption tool and format - kmos
https://docs.google.com/document/d/11yHom20CrsuX8KQJXBBw04s80Unjv8zCg_A7sPAX_9Y/preview
======
danielparks
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
I’m not sure I understand, what’s the difference? I’ve never had any problems
using go programs’ command line flags myself.

~~~
oarsinsync
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.

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

~~~
lann
You are misunderstanding what you are seeing. The Z does not represent a
literal Z in parsing/formatting.

[https://play.golang.org/p/Qp-bBtzKpG-](https://play.golang.org/p/Qp-bBtzKpG-)

~~~
lozf
OK, Thanks for clearing that up.

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

------
fanf2
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
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...](https://twitter.com/filosottile/status/1180861642546073600?s=21)

~~~
fanf2
Oh, that has become a lot more promising in the last couple of days :-)

------
bertman
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/)

------
teddyh
What is the point of this when we already have symcryptrun?

[https://gnupg.org/documentation/manuals/gnupg/symcryptrun.ht...](https://gnupg.org/documentation/manuals/gnupg/symcryptrun.html#symcryptrun)

~~~
detaro
I don't understand how that link describes something that invalidates this?

~~~
teddyh
Symcryptrun does more or less exactly what this document proposes to
implement. It doesn’t _invalidate_ it, it renders it unnecessary.

------
snek
Could update link to age-tool.com.

~~~
inetsee
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
The repo:
[https://github.com/FiloSottile/age](https://github.com/FiloSottile/age)

------
nothingnewhere
>(...) it’s pronounced like the Japanese 上げ (with a hard g).

Now somebody just needs to write it in Rust or Haskell...

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

Yawn.

~~~
dang
Please don't do this here.

