1,837 karma · joined August 27, 2013
email: mark.samman@gmail.com
twitter: https://twitter.com/marksamman
[ my public key: https://keybase.io/marksamman; my proof: https://keybase.io/marksamman/sigs/6oprLFSCu4KE4g_vbAzrbPRtms_W-YDssommqRYhFes ]
Wire has also open-sourced their clients and a lot of components, so even if they were to vanish as a company, all work is not lost.
Finding a replacement isn't easy, but I've used Wire (wire.com) for a year now and find it good enough feature-wise, and excellent security-wise. It has its quirks and can be a resource hog at times (the desktop app uses Electron IIRC), but it's worth switching from the security disaster that is Skype.
In order to secure nginx against privilege escalation attacks, we are
changing the way log file owners & permissions are handled so that www-data
is not allowed to symlink a logfile. /var/log/nginx is now owned by root:adm
and its permissions are changed to 0755. The package checks for such symlinks
on existing installations and informs the admin using debconf.
That unfortunately may come at a cost in terms of privacy. /var/log/nginx is
now world-readable, and nginx hardcodes permissions of non-existing logs to
0644. On systems running logrotate log files are private after the first
logrotate run, since the new log files are created with 0640 permissions.
-- Christos Trochalakis <yatiohi@ideopolis.gr> Tue, 04 Oct 2016 15:20:33 +0300For Gmail users, it's a good practice to register to websites using username+websitename@gmail.com (e.g. mark.samman+hackernews@gmail.com), that way you'll know who leaked your data when it appears in lists like this or when you get spam. Gmail ignores the plus character and anything that follows the plus. You can also add dots at arbitrary positions in the username part.
You can't grow the size you allocated with new[] in-place, and because you need to retain the existing data it's not safe to delete[] the old buffer, call new[] and hope that it points to the previous memory address and assume that the existing data remains intact.
A realloc implementation can try to grow the buffer if there's contiguous space, and if it succeeds it doesn't need to deallocate or copy anything. I haven't had a look at realloc implementations so I don't know if that, or other optimizations are done in practice, but I assume that realloc's worst performance case is somewhere around new[], copy and delete[]'s best case.
The copy mechanism in std::vector may also have a significant overhead over realloc if it has to call the copy constructor (or ideally move constructors in C++11) of every object in the vector, although I can imagine a C++ equivalent of realloc doing so too.
[1] https://zmap.io/documentation.html
EDIT: The research paper says that it's on a particular port, from page 3: "The architecture allows sending and receiving components to run asynchronously and enables a single source machine to comprehensively scan every host in the public IPv4 address space for a particular open TCP port in under 45 mins using a 1 Gbps Ethernet link."