From: "Daniel P. Berrange" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 1/5] util: add base64 decoding function
Date: Wed, 9 Dec 2015 12:50:36 +0000 [thread overview]
Message-ID: <20151209125036.GD19914@redhat.com> (raw)
In-Reply-To: <566702D6.7000201@redhat.com>
On Tue, Dec 08, 2015 at 09:18:30AM -0700, Eric Blake wrote:
> On 11/27/2015 09:30 AM, Daniel P. Berrange wrote:
> > The standard glib provided g_base64_decode doesn't provide any
> > kind of sensible error checking on its input. Add a QEMU custom
> > wrapper qbase64_decode which can be used with untrustworthy
> > input that can contain invalid base64 characters, embedded
> > NUL characters, or not be NUL terminated at all.
> >
> > Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> > ---
>
> > +
> > +/**
> > + * qbase64_decode:
> > + * @input: the (possibly) base64 encoded text
> > + * @in_len: length of @input or -1 if NUL terminated
> > + * @out_len: filled with length of decoded data
> > + * @errp: pointer to uninitialized error object
>
> That almost implies that I could do:
>
> Error *err;
> qbase64_decode(,&err);
>
> In reality, it should be the NULL-initialized error object, as in:
>
> Error *err = NULL;
>
> but I don't know if there is a better way to represent it in text. At
> any rate, that phrase exists elsewhere, so it would be easier to do a
> tree-wide cleanup if we have a better terminology to use, and I won't
> hold up review on this patch for it.
Yep, most of those comments will be my fault, since that's the standard
doc text I've been adding for @errp parameters. I'll fix this one
and also do a general cleanup patch for others separately.
> > +static void test_base64_bad(const char *input,
> > + size_t input_len)
> > +{
> > + size_t len;
> > + Error *err = NULL;
> > + uint8_t *actual = qbase64_decode(input,
> > + input_len,
> > + &len,
> > + &err);
> > +
> > + g_assert(err != NULL);
>
> Could use &error_abort in the original call instead of a second check
> for err != NULL; but that's cosmetic.
Actually we can't use &error_abort, as we don't want the test
function to abort on error as that would indicate test failure.
We want to make sure the call completes & returns an error
set without aborting.
> > + g_assert(actual == NULL);
> > + g_assert_cmpint(len, ==, 0);
>
> So you are testing that we initialize output length even on error,
> rather than leaving it uninitialized. That's fair.
> > +static void test_base64_embedded_nul(void)
> > +{
> > + const char input[] = "There's no such\0thing as a free lunch.";
> > +
> > + test_base64_bad(input, G_N_ELEMENTS(input) - 1);
> > +}
> > +
>
> This asserts that you have a failure, but doesn't say what that failure
> would be...
>
> > +
> > +static void test_base64_not_nul_terminated(void)
> > +{
> > + char input[] = "There's no such thing as a free lunch.";
> > + input[G_N_ELEMENTS(input) - 1] = '!';
> > +
> > + test_base64_bad(input, G_N_ELEMENTS(input) - 1);
> > +}
> > +
> > +
> > +static void test_base64_invalid_chars(void)
> > +{
> > + const char *input = "There's no such thing as a free lunch.";
> > +
> > + test_base64_bad(input, strlen(input));
> > +}
>
> ...and this same input already fails because it doesn't match base64,
> regardless of whether NUL bytes are mishandled. I wonder if
> test_base64_embedded_nul() and test_base64_not_nul_terminated() should
> be using variations of your known-good base64 string
> ("QmVjYXVzZSB3ZSBmb2N1c2VkIG9uIHRoZSBzbmFrZSwgd2UgbW\n"
> "lzc2VkIHRoZSBzY29ycGlvbi4="), to prove that they are failing purely
> because of the NUL handling and not because of invalid base64 content.
That's a good idea - I'll respin with that an add more comments
about what we're testing for in each case.
> But that's only a weak complaint - because by peering into the black
> box, I see that you are fully testing all code paths (that is, the black
> box checks for NUL abuse prior to checking for valid base64 data), so
> I'm not going to insist on a respin.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
next prev parent reply other threads:[~2015-12-09 12:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-27 16:30 [Qemu-devel] [PATCH v3 0/5] Add framework for passing secrets to QEMU Daniel P. Berrange
2015-11-27 16:30 ` [Qemu-devel] [PATCH v3 1/5] util: add base64 decoding function Daniel P. Berrange
2015-12-08 16:18 ` Eric Blake
2015-12-09 12:50 ` Daniel P. Berrange [this message]
2015-12-09 15:18 ` Eric Blake
2015-11-27 16:30 ` [Qemu-devel] [PATCH v3 2/5] qemu-char: convert to use error checked base64 decode Daniel P. Berrange
2015-11-27 16:30 ` [Qemu-devel] [PATCH v3 3/5] qga: " Daniel P. Berrange
2015-11-27 16:30 ` [Qemu-devel] [PATCH v3 4/5] crypto: add QCryptoSecret object class for password/key handling Daniel P. Berrange
2015-12-08 16:49 ` Eric Blake
2015-12-09 12:56 ` Daniel P. Berrange
2015-11-27 16:30 ` [Qemu-devel] [PATCH v3 5/5] crypto: add support for loading encrypted x509 keys Daniel P. Berrange
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151209125036.GD19914@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.