To address this type of attacker, we present Oblivious DNS (ODNS), which is
a new design of the DNS ecosystem that allows current DNS servers to remain
unchanged and increases privacy for data in motion and at rest. In the ODNS
system, both the client is modified with a local resolver, and there is a
new authoritative name server for .odns. To prevent an eavesdropper from
learning information, the DNS query must be encrypted; the client generates
a request for www.foo.com, generates a session key k, encrypts the
requested domain, and appends the TLD domain .odns, resulting in
{www.foo.com}k.odns. The client forwards this, with the session key
encrypted under the .odns authoritative server’s public key ({k}PK) in the
“Additional Information” record of the DNS query to the recursive resolver,
which then forwards it to the authoritative name server for .odns. The
authoritative server decrypts the session key with his private key, and
then subsequently decrypts the requested domain with the session key. The
authoritative server then forwards the DNS request to the appropriate name
server, acting as a recursive resolver. While the name servers see incoming
DNS requests, they do not know which clients they are coming from;
additionally, an eavesdropper cannot connect a client with her
corresponding DNS queries.
—
Oblivious DNS project at Princeton
Up till now, writers of crypto and security software not only have to fight
the bad guys. We also have to deal with compiler writers, who every so
often dream up some new optimisation routine which spots the padding
instructions that we put in to make our crypto algorithms run in constant
time, or the tricks that we use to ensure that sensitive data will be
zeroised when a function returns. All of a sudden some critical code is
optimised away, your code is insecure, and you scramble to figure out how
to outwit the compiler once more.
So while you’re fighting the enemy in front, the compiler writer is a
subversive fifth column in your rear.
—
Ross
Anderson
Last year, the Defcon hackers' conference
sponsored
[PDF] a Voting
Village. Organizers collected 25 pieces of voting equipment, including
voting machines and electronic poll books. By the end of the weekend,
conference attendees had found ways to compromise every piece of test
equipment: to load malicious software, compromise vote tallies and audit
logs, or cause equipment to fail.
It's important to understand that these were not well-funded nation-state
attackers. These were not even academics who had been studying the problem
for weeks. These were bored hackers, with no experience with voting
machines, playing around between parties one weekend.
—
Bruce
Schneier
Comments (18 posted)
The current development kernel is 4.17-rc2,
released on April 22. Quoth Linus:
"
We've still got some known fallout from the merge window, but it
shouldn't affect most normal configurations, so go out and test.
"
Stable updates:
4.16.3, 4.15.18, and 4.14.35 were released on April 19;
4.9.95 followed one day later. Then 4.16.4, 4.14.36, 4.9.96, 4.4.129, and 3.18.106 were released on April 24.
Note that
4.15.18 is
the end of the line for the 4.15.x series.
The 4.16.5 and
4.14.37 updates are in the review process;
they are due on April 27.
Comments (none posted)
The 4.17 merge window included a change in the behavior of the
CLOCK_MONOTONIC system clock; in particular, it would advance
after a resume to reflect the time that the system was suspended. At the
time, the developers involved acknowledged that the change might have to be
reverted if it caused regressions. It seems that some such regressions
have indeed been reported, so
a
revert has been queued with this comment:
As reported by several folks systemd and other applications rely on
the documented behaviour of CLOCK_MONOTONIC on Linux and break with
the above changes. After resume daemons time out and other timeout
related issues are observed.
It's sad, that these problems were neither catched in -next nor by
those folks who expressed interest in this change.
Comments (6 posted)
Daniel Vetter
looks at
some kernel-development statistics, with a focus on patches written by
the maintainers who commit them. "
Naively extrapolating the relative trend predicts that around the year 2025 large numbers of kernel maintainers will do nothing else than be the bottleneck, preventing everyone else from getting their work merged and not contributing anything of their own. The kernel community imploding under its own bureaucratic weight being the likely outcome of that.
This is a huge contrast to the 'everything is getting better, bigger, and
the kernel community is very healthy' fanfare touted at keynotes and the
yearly kernel report. In my opinion, the kernel community is very much not
looking like it is coping with its growth well and an overall healthy
community.
"
Comments (10 posted)
As the Linux networking maintainer, I feel the need to reiterate my
statement of a month ago, and to provide some supporting facts on
my end so that there is no confusion in the community on these
issues.
I am no longer associated with either the Netdev Society or their
event, the NetDev conference.
Neither is endorsed nor supported by me.
—
David Miller
Comments (21 posted)
Debian itself will always face challenges but I sincerely believe that the Project remains as healthy as ever. We are uniquely cherished and remain remarkably poised to improve the free software ecosystem as a whole. Moreover, our stellar reputation for technical excellence, stability and software freedom remains highly respected and without peer. It is truly an achievement to be proud of.
—
Chris
Lamb
Comments (none posted)
Version 4.0 of the FFmpeg
multimedia toolkit is out. There is a long list of new filters, formats,
and more; see the announcement for details.
Comments (1 posted)
Who cares about performance of a terminal emulator, if it can't draw emojis? I mean, please, let's focus on the important things, and I take emojis a thousand times over frickin' speed, thank you very much...
😬 😬 😬
—
Lennart Poettering
BTW, building a 400 line library and writing reams of control code for a fridge that has not been installed yet is what we Haskell programmers call "laziness".
—
Joey
Hess
Of course, I didn't only remove stuff; I also added things like more efficient sorting of strings, added a new microbenchmark framework, sped up the new Unicode 9.0 collations by 20x, and probably added some legacy on my own. :-) But sometimes, it's good to remove. Remove some code today!
—
Steinar
H. Gunderson (Thanks to Paul Wise)
Comments (none posted)