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>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
