gpg > addphoto

[Peter Lebbing]

Hi Stefan,

On 08/01/2019 17:39, Stefan Claas wrote:
> To be honest i don't understand why this was implemented this way in
> the first place

I'm just guessing, I don't know for sure. But since it seems you're
unclear about what I meant, I'm trying to explain that.

I don't think this implementation is meant to restrict users in creating
image attributes at all. It's not meant as some means to stop a user
from creating a mega-large image. So you're coming at it from the wrong
direction when you say "isn't this a bit too much to allow".

Rather, it's meant as a means to prevent *reading* such a large image.
With all software, but with crypto even more, you need to build in
defenses against people trying to create a mess for others.

So suppose someone created a public key containing some mega-large
image, or corrupting a public key to contain nonsense data. In this
case, when you import this key and your GnuPG is reading this data it
needs to have some safeguards against malfunctioning. You ask why it was
implemented this way. The reasoning is: nobody bona fide would ever
create an (image) attribute larger than 16 MiB. In fact, it would be
much less, but we're being conservative and saying: well, no matter the
circumstances, 16 MiB is certainly ridiculous. So if GnuPG ever
encounters an attribute larger than 16 MiB, it should just stop and
display an error instead of trying to continue. Because clearly
something fishy is going on. A real attribute will always be much
smaller. That's a reason to halt and give up.

So, yes, 16 MiB is ridiculous. That's the point. It's a test to see
whether we are doing something that we're supposed to be doing, or
whether we're looking at something ridiculous.

So when you say "Shouldn't users be forced to limit themselves to
something much smaller?", that's simply a different subject as I
understand it. This 16 MiB has nothing to do with that, it's a different
mechanism.

I hope I did a good job of explaining my meaning this time around.

But I'd like to tack on even more thoughts :-). Because finally, what
GnuPG enforces is again something different from what the keyserver
network enforces. If you're worried about big images or other data being
uploaded to the keyservers, the place to fix that would be the
keyservers, not GnuPG, because a bad actor could just change their own
GnuPG. But they can't change the code running in the public keyserver
network other than by running their own keyserver.

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190108/66500d8f/attachment.sig>