Re: Lite mode is in SVN -- mostly
On Wed, Jul 29, 2009 at 3:41 PM, ijuma ism...@juma.me.uk wrote: Is there a way to disable this behaviour? As you say, it doesn't seem particularly useful for sophisticated JVMs and unless I am missing something, the queue is currently unbounded so it could end up retaining quite a bit of memory for some usage patterns. There's no way to disable it at present, but I would be fine with adding a way. In fact I think this should probably be off by default. Best, Ismael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Allow setting compression level on GzipOutputStream
Reviewers: peter.keen_gmail.com, Description: Hi Peter, I decided to extend this patch a bit. I didn't like all the default options to the constructor, so I created a separate Options struct -- this way people don't have to set a buffer size in order to set compression level (which is good because almost no one should care about buffer size). I also added tests. At Google we have a policy of reviewing all code before submission, so please take a look at the diffs and let me know if it looks good to you. Please review this at http://codereview.appspot.com/96211 Affected files: M src/google/protobuf/io/gzip_stream.cc M src/google/protobuf/io/gzip_stream.h M src/google/protobuf/io/zero_copy_stream_unittest.cc --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Allow setting compression level on GzipOutputStream
On 2009/07/31 23:56:40, kenton wrote: This looks great, Kenton. Thanks for cleaning it up! The tests look pretty decent as well. With such a small golden message you're probably not going to see any difference between the different compression levels, and it is just passed through to zlib so there's probably no point in testing it here. http://codereview.appspot.com/96211 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Allow setting compression level on GzipOutputStream
Yeah, the test only compares default compression to no compression -- even with the small message, default compression manages to compress a little bit. Committed as rev 170. On Fri, Jul 31, 2009 at 5:08 PM, peter.k...@gmail.com wrote: On 2009/07/31 23:56:40, kenton wrote: This looks great, Kenton. Thanks for cleaning it up! The tests look pretty decent as well. With such a small golden message you're probably not going to see any difference between the different compression levels, and it is just passed through to zlib so there's probably no point in testing it here. http://codereview.appspot.com/96211 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
text relocation inside libprotoc.so.4.0.0
A question on the right behavior of libprotoc.so.4.0.0. On a CentOS 5.1, I downloaded and installed the latest protocol buffer 2.1. Make check runs fine. Then when I tried to do make under the ./ example directory, SELinux reports that protoc attempted to load /usr/ local/lib/libprotoc.so.4.0.0 which requires text relocation. This is a potential security problem. The command I run is simply: protoc --cpp_out=. addressbook.proto which reports from CLI that cannot restore segment proc after reloc: Permission Denied While I don't believe the code has malicious intention, just curious that is this text relocation inside libprotoc.so.4.0.0 a correct behavior? I hesitate to allow the this exception in SELinux before I get confirmation. Thanks, Hank --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: text relocation inside libprotoc.so.4.0.0
I think text relocation has something to do with the way a dynamic library is compiled and/or loaded. This is not something which Protocol Buffers asks for specifically -- either libtool, your linker, or your binary loader chose to use this feature without being asked for it. It seems that SELinux feels that text relocation is risky because it means that the library image in memory is both executable and writable, which presumably makes it easier to exploit buffer overruns -- but first a buffer overrun has to exist, independently. So this isn't a security hole in itself, it's just something that could hypothetically make some other security hole more exploitable. Possible solutions: * Compile protobuf with static linking only. (configure --disable-shared) * Figure out how to compile protobuf with text relocation disabled, and do that. (Maybe CFLAGS=-fPIC will do it? But note that this will make the code a bit slower.) * Tell your OS to allow text relocation for protoc because protoc does not process data from potentially malicious users and therefore is not a security risk. On Fri, Jul 31, 2009 at 6:43 PM, hw...@gear6.com hw...@gear6.com wrote: A question on the right behavior of libprotoc.so.4.0.0. On a CentOS 5.1, I downloaded and installed the latest protocol buffer 2.1. Make check runs fine. Then when I tried to do make under the ./ example directory, SELinux reports that protoc attempted to load /usr/ local/lib/libprotoc.so.4.0.0 which requires text relocation. This is a potential security problem. The command I run is simply: protoc --cpp_out=. addressbook.proto which reports from CLI that cannot restore segment proc after reloc: Permission Denied While I don't believe the code has malicious intention, just curious that is this text relocation inside libprotoc.so.4.0.0 a correct behavior? I hesitate to allow the this exception in SELinux before I get confirmation. Thanks, Hank --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
