signify(1): make comments optional

[Ivan Markin]

At the moment signify(1) requires sigfiles to begin with 'untrusted
comment: '. Sometimes one wants to have no comments and just signature
itself.

Index: signify.c
===================================================================
RCS file: /cvs/src/usr.bin/signify/signify.c,v
retrieving revision 1.126
diff -u -p -r1.126 signify.c
--- signify.c 6 Oct 2016 22:38:25 -0000 1.126
+++ signify.c 11 Oct 2016 00:19:35 -0000
@@ -125,27 +125,33 @@ static size_t
parseb64file(const char *filename, char *b64, void *buf, size_t buflen,
char *comment)
{
- char *commentend, *b64end;
+ char *linebegin, *lineend;

- commentend = strchr(b64, '\n');
- if (!commentend || commentend - b64 <= COMMENTHDRLEN ||
- memcmp(b64, COMMENTHDR, COMMENTHDRLEN) != 0)
- errx(1, "invalid comment in %s; must start with '%s'",
- filename, COMMENTHDR);
- *commentend = '\0';
- if (comment) {
- if (strlcpy(comment, b64 + COMMENTHDRLEN,
- COMMENTMAXLEN) >= COMMENTMAXLEN)
- errx(1, "comment too long");
+ linebegin = b64;
+ lineend = strchr(linebegin, '\n');
+ if (!lineend) {
+ errx(1, "not enough lines in %s", filename);
}
- if (!(b64end = strchr(commentend + 1, '\n')))
- errx(1, "missing new line after base64 in %s", filename);
- *b64end = '\0';
- if (b64_pton(commentend + 1, buf, buflen) != buflen)
- errx(1, "invalid base64 encoding in %s", filename);
+ if (lineend - linebegin > COMMENTHDRLEN &&
+ memcmp(b64, COMMENTHDR, COMMENTHDRLEN) == 0) {
+ *lineend = '\0';
+ if (comment) {
+ if (strlcpy(comment, b64 + COMMENTHDRLEN,
+ COMMENTMAXLEN) >= COMMENTMAXLEN)
+ errx(1, "comment too long");
+ }
+ linebegin = lineend + 1;
+
+ if (!(lineend = strchr(linebegin, '\n')))
+ errx(1, "missing new line after base64 in %s",
filename);
+ }
+
+ *lineend = '\0';
+ if (b64_pton(linebegin, buf, buflen) != buflen)
+ errx(1, "invalid base64 encoding or corrupted comment in
%s", filename);
if (memcmp(buf, PKALG, 2) != 0)
errx(1, "unsupported file %s", filename);
- return b64end - b64 + 1;
+ return lineend - b64 + 1;
}

static void

[Theo de Raadt]

Hi Ivan. Think I know who you are, and can guess why.

This seems misguided. We have a horrible program called "file", but
in general people identify what a file is what what purpose it serves
not just by the filename, but also by how it starts. The "untrusted
comment" has become the way to identify a signify file. It has become
colloquial.

Yes, there is a magic number immediately after that, but it is at
unknown byte offset. It isn't a offset-addressed file like gzip. So
your proposal doesn't actually help solve anything, in fact it
increases the ambiguity.

So why not consider that call it a day, and leave it alone?

[Ivan Markin]

Hi Theo,

Theo de Raadt:

> This seems misguided. We have a horrible program called "file", but
> in general people identify what a file is what what purpose it serves
> not just by the filename, but also by how it starts. The "untrusted
> comment" has become the way to identify a signify file. It has become
> colloquial.
>
> Yes, there is a magic number immediately after that, but it is at
> unknown byte offset. It isn't a offset-addressed file like gzip. So
> your proposal doesn't actually help solve anything, in fact it
> increases the ambiguity.

Nice catch, I haven't thought about file(1).
I consider file(1) really useful. But at the same time it's way too
empirical/phenomenological. Sometimes it's unable to reliably tell the
truth. Only corresponding program/codec can tell if a file really
contains data if this type. [in out case it's signify(1)].
Should we duplicate codec logic and put in into separate file(1)?
Not the best idea.
Can we include all the types info/magic just into one file(1) utility
(/etc/magic)?
No.
Should we create filetypes to be detectable by file(1)?
Don't think so.

> So why not consider that call it a day, and leave it alone?

Just because.

--
Ivan Markin

[Theo de Raadt]

I've pointed out that people identify the purpose of the file in various ways.

You wish to basically throw that out?

> > So why not consider that call it a day, and leave it alone?
>
> Just because.

Well I don't see any need to introduce incompatible variations.

[Ivan Markin]

Theo de Raadt:

> I've pointed out that people identify the purpose of the file in
various ways.
> You wish to basically throw that out?

All I say is that file(1) is unreliable by design. And I don't think one
needs to care about it too much just because someone got used to it.
Personally I consider option to have no comment useful. More useful than
looking at 'this is signified something' kind of message.

> Well I don't see any need to introduce incompatible variations.

Yeap, there is a problem with verifying uncommented signatures on
current signify(1). I don't care. And it's okay if someone does - I've
just put my two cents.

--
Ivan Markin

[Theo de Raadt]

> Theo de Raadt:
> > I've pointed out that people identify the purpose of the file in
> various ways.
> > You wish to basically throw that out?
>
> All I say is that file(1) is unreliable by design.

You didn't continue reading. And you persist in not going back.

> > Well I don't see any need to introduce incompatible variations.
>
> Yeap, there is a problem with verifying uncommented signatures on
> current signify(1). I don't care. And it's okay if someone does - I've
> just put my two cents.

they don't need to be verified. They are informational.

[Ivan Markin]

Theo de Raadt:

>> > Yeap, there is a problem with verifying uncommented signatures on
>> > current signify(1). I don't care. And it's okay if someone does - I've
>> > just put my two cents.
> they don't need to be verified. They are informational.

Okay, I meant signified files without a comment line.

atm, one can't verify signature if 'untrusted comment: ' line is not there.
Yes, they are _informational_. That's why I think they should be optional.

--
Ivan Markin

[Theo de Raadt]

But they are not optional.

This is a subsystem where strictness is is a good thing.

[Theo de Raadt]

> >> > Yeap, there is a problem with verifying uncommented signatures on
> >> > current signify(1). I don't care. And it's okay if someone does - I've
> >> > just put my two cents.
> > they don't need to be verified. They are informational.
>
> Okay, I meant signified files without a comment line.

All signified files contain that comment.

You might not like it. But the ship sailed. It's too bad you didn't
invent this stuff.

[Ivan Markin]

Theo de Raadt:

> You might not like it. But the ship sailed. It's too bad you didn't
> invent this stuff.

As I said, it's convenient for me. Maybe also for someone else. This is
all I care about.

--
Ivan Markin

[Theo de Raadt]

You'll break other people's compatility without a thought.

You only care about yourself.

Yeah, that much is clear.

[Ivan Markin]

Theo de Raadt:

> You'll break other people's compatility without a thought.
>
> You only care about yourself.
>
> Yeah, that much is clear.

Theo, your insults are pointless. But your concerns are not.
I don't want to break anything. I think that if something is useful
enough for others one can find a way out without breaking anything.

--
Ivan Markin

[Theo de Raadt]

But you do want to break compatibility. Your own signify code
will soon generate files that the OpenBSD one cannot parse.

That is why you are trying to push changes into an established
ecosystem, WITHOUT JUSTIFICATION. Your only justification was
"because I want to do so".

Look Ivan, don't be a child. Justify your actions and your words.
Explain what you are changing, and why. Measure the impact. Don't
wave it away. Waving away other people's concerns away does not count
as jusification. It makes you look like an uncaring ass.

If I was kind I would not even reply, because you are being a jerk
only thinking of yourself.

If you cared so much about what signify does and why it is what it
is, you would have invented it first. But you didn't, did you.

[Ivan Markin]

Theo de Raadt:

> That is why you are trying to push changes into an established
> ecosystem, WITHOUT JUSTIFICATION. Your only justification was
> "because I want to do so".

Read this tread carefully and you'll see that I don't *push* anything. I
don't consider one lonely patch on tech@ as pushing. tech@ is still the
upstream for signify(1). Why not leave it alone if you don't like to
merge it?

I'm not going to answer to another portion of pointless insults below.
Just wondering how can you produce such amount of it out nothing.

> Look Ivan, don't be a child. Justify your actions and your words.
> Explain what you are changing, and why. Measure the impact. Don't
> wave it away. Waving away other people's concerns away does not count
> as jusification. It makes you look like an uncaring ass.
>
> If I was kind I would not even reply, because you are being a jerk
> only thinking of yourself.
>
> If you cared so much about what signify does and why it is what it
> is, you would have invented it first. But you didn't, did you.

--
Ivan Markin

[Theo de Raadt]

> > That is why you are trying to push changes into an established
> > ecosystem, WITHOUT JUSTIFICATION. Your only justification was
> > "because I want to do so".
>
> Read this tread carefully and you'll see that I don't *push* anything. I
> don't consider one lonely patch on tech@ as pushing. tech@ is still the
> upstream for signify(1). Why not leave it alone if you don't like to
> merge it?
>
> I'm not going to answer to another portion of pointless insults below.
> Just wondering how can you produce such amount of it out nothing.

Ivan, you bothered to write the diff and reply quite a few times, but
you waived all the concerns aside.

It's your problem not mine.

[Ivan Markin]

Theo de Raadt:

> Ivan, you bothered to write the diff and reply quite a few times, but
> you waived all the concerns aside.

This was just my opinion on this. Nothing less, nothing more.

> Don't post diffs you don't want to defend.

Should I defend? I posted it because I want to share.

> You have a problem; when I ask question and you delete text and wave
> your hands in dismissal, it is not I that have a problem, but you.

There is no problem.

--
Ivan Markin

[Marc Espie]

The comments are a necessary feature these days, actually.

It is slightly warped: it says "untrusted comment" because it's outside
of the signed area and shouldn't be taken at face value, BUT if you have
the right public key, AND manage to validate the signature with it, then
it means that it *was* the right key, so in retrospect, you are assured that
it was the right key.

So it says exactly what it means "hey, try that key, you can't be sure it's
the right one, but in retrospect, if it works then you can be sure it WAS
the right key".

Of course, it doesn't say so in so many words. But it is a very accurate
message.

So it should stay, 100% of the time.

[Ivan Markin]

Hi Marc,

Marc Espie:

Yes, you're absolutely right about purpose of this comment.
This patch doesn't stop signify(1) from embedding a comment string
before signature. It just makes it possible to verify signatures even if
there is no 'untrusted comment: ' string in them.

--
Ivan Markin

[Ivan Markin]

Ivan Markin:

> Yes, you're absolutely right about purpose of this comment.
> This patch doesn't stop signify(1) from embedding a comment string
> before signature. It just makes it possible to verify signatures even if
> there is no 'untrusted comment: ' string in them.

Sorry that it is not clear from the patch description. Actually it
doesn't break compatibility since it still produces signatures as before.

--
Ivan Markin