You are not logged in.
I've uploaded a hardened prefs.js (aka "about:config") which has some tweaks that I use. I splice it into a fresh *.default before adding any add-ons. It should work with 56+ (including waterfox). Anyone is free to try or use it; just make sure to back-up your original prefs.js first.
Please note that this configuration is best when coupled with other security and privacy addons (eg noscript), and no addon beats disabling javascript altogether (although this may be unreasonable for all users).
A note about privacy.resistFingerprinting in Quantum -- when this "privacy" feature is enabled, it also leaks default information (check yourself at browserleaks.com/javascript). I disable this feature and use the canvasblocker plugin instead. (Mozilla in general seems to be implementing "privacy" and "security" features at the cost of, ironically, privacy and security; tracking protection is another example, as it offloads requests to Google. This is an unsettling trend, although understandable since, if I recall, Google is a huge donator to Mozilla.)
There was a short-lived conversation on FDN about firejail a few months ago. I thought it important to remember that truly paranoid users need pay mind to hardware and their kernel.
http://forums.debian.net/viewtopic.php?p=644598#p644598
Also, the Linux kernel itself is vulnerable to a broad range of exploits thanks to the developers' refusal to prioritise security-related bugs until relatively recently.
So to presume that the same developers can then conjure up a "secure layer" is rather optimistic, in my opinion.
There have been many demonstrated vulnerabilities in the kernel namespace feature (used by firejail & co.), I think it would be folly to rely on it too much.
I can recommend OpenBSD for online banking use, their kernel has been designed with exploit prevention in mind for the last 20 years 8)
Always remember:
NSA wrote:Security is a state of mind.
In terms of Palemoon tips, while I'm using it a lot less these days (solely because of webkit limitations), the biggest asset is researching, trying new plugins, and if they break, research any alternatives. One of the best plugins is Palemoon Commander, which gives you access to an incredible amount of security and privacy options. You can also make most of the same tweaks as you could with firefox in about:config.
Unfortunately, don't expect too much, because mainstream Firefox is completely changing, and it's disincentivizing past addons' developers from continuing backward compatibility; uMatrix, which offers script-blocking utilities, no longer works, and I'm getting the sense that noscript compatibility has died as well -- all of which is a shame. That coupled along with trivial disputes between Moonchild Studios and other distributions, including openbsd, and I'm not sure I see much light at the end of Palemoon's tunnel. There's another thread here about different browsers, if you'd like to see a comparison: https://dev1galaxy.org/viewtopic.php?id=1697
^golinux is right. Apparently this isn't news, either. XD So you may want to try sudo apt-get install linux-headers-$(dpkg --print-architecture) instead.
E: The "linux-headers-generic" package does not have a candidate for installation
My guess is you need to remove the duplicate cdrom line, so your sources.list would read something like:
# deb cdrom:[devuan_ascii_2.0.0-rc_amd64_dvd-1]/ ascii main non-free
deb http://mx.deb.devuan.org/merged ascii main non-free contrib
[ ... ]
Then run sudo apt-get update and re-run the other command, with the dependencies, that I mentioned in my first reply.
If that works, it may help with your Input/Output issue. It might be a problem with your kernel package, so you could try re-installing the kernel, like the person in that link did. But I suspect that fixing your sources.list and updating will solve a few conundrums.
Says you.
I usually use chunks of rock salt pasted together with hardened lard and envision bacon. Cheaper than the store-bought bacon bits and just as good imho.
Did you even look at the photo?
Can you post the full output of sudo apt-get install -y linux-headers-generic build-essential dkms?
Also, your wifi card model -- sudo lspci -vv | grep -i network -- and a link to your driver might be helpful, too.
figdev,
What you have to understand is that dev1galaxy.org is actually build through a network of potatoes and copper wires. Extrenuous elements, like CSS and images, are offloaded through a private Windows 2003 server in China; but the transmission of text, what you're using to write your responses, it's all ripe Idaho potatoes.
Overall, this makes for a more secure network, because you can set up your own chain of potato nodes from your location to a nearby one -- the closest one to my area is only a hundred miles away or so. And because it's relatively obscure, government firewalls aren't blocking the potato transmission protocol, so PTP messages can still get through.
The downside (or upside, in your case) is that the ONLY thing users and moderators can do is send and read text, like we're doing now. Some of the more advanced forum features, such as banning, are impossible. The Debian forums might ban members for consistent offtopic tirades, but due to the potatoes' limitations, it is literally impossible to perform a ban here.
By now, you're probably thinking, "this is complete science fiction." You're wrong. Idaho potatoes have existed since at least the 1950s, following other scientific developments such as the Gutenberg printing press and the refrigerator. Still don't believe me? Check it out: photographic evidence of an actual Idaho potato. Where's that inflexible skepticism now?
In sum, it is absurd that members are accusing the forums of not being build through a matrix of underground potatoes. If that is the beliefs of certain members, it may do them well to spend some time on a potato farm, or consider creating a farm of one's own. But to say that infrastructures cannot, and ARE not, built on this tried-and-true networking framework is ignorance at its best. Do some research before commenting.
I resonate GNUser's idea.
Maybe it's time to make a Trisquel forum account...
Alright, I understand what you're saying now. It sounded like you were implying the symmetric part of the attack was factually wrong, ie not part of the attack lol.
It is still in draft phase (0.9.0 at this time). We'll see if it changes at all.
I totally agree, and I was not referring to your article, rather to the original one.
The article in the original post? If so, they also published the paper as well.
This part is irrelevant to the exploit, and is also factually wrong.
Forgive me for finding this weird, because...
Since our attacks exploit weaknesses in the symmetric encryption, we focus on the symmetric encryption part.
So that would seem to be a key component of the attack.
If I'm reading your posts correctly, and I believe you, but I'm concerned that there would be irrelevant misinformation in the paper about this attack. I'll reach out to them and see if we can get clarification on some of these points.
The article is really misleading, and the way it has been advertised is even more misleading.
Since they're the ones who published the actual paper, it may be a good idea to tell them to stop spreading FUD.
It's not PGP or OpenPGP to have been exploited, rather the uncanny behaviour of sending, receiving, and automatically visualising multipart emails containing external references (e.g., HTML tags which are interpreted by the MUA).
I believe you. Can you help me understand how to interpret this segment of page 3 in the paper:
2.1 Cryptographic basics
In the email context, both S/MIME and PGP use hybrid encryption, in which the sender generates a random session key "s" that is used to symmetrically encrypt the message "m" into a cipher text "c."
The session key "s" is encrypted with at least two public keys using a public key encryption scheme. The first encryption of "s" happens with the public key of the sender. Additional encryptions are done using all the public keys of the intednded recievers. Thus, "s" will be encrypted under n+1 different public keys for "n" recipients of the email. Since our attacks exploit weaknesses in the symmetric encryption, we focus on the symmetric encryption part.
@figdev - I resonate the sentiment that it's imprudent to assume one will not be exploited at some point on a computer. It is a little disconcerting, but it's good that there are ways to mitigate it.
@golinux - suffice it to say the result of ignorance of an email infrastructure I was using.
Added a note at the top of the first post, for a list of email clients' vulnerability status.
Full publication on EFAIL.de. In particular, page 11 of the PDF contains a list of clients that were tested, along with the results.
EFAIL describes vulnerabilities in the end-to-end encryption technologies OpenPGP and S/MIME that leak the plaintext of encrypted emails.
Here are some strategies to prevent EFAIL attacks:
Short term: No decryption in email client. The best way to prevent EFAIL attacks is to only decrypt S/MIME or PGP emails in a separate application outside of your email client. Start by removing your S/MIME and PGP private keys from your email client, then decrypt incoming encrypted emails by copy&pasting the ciphertext into a separate application that does the decryption for you. That way, the email clients cannot open exfiltration channels. This is currently the safest option with the downside that the process gets more involved.
Short term: Disable HTML rendering. The EFAIL attacks abuse active content, mostly in the form of HTML images, styles, etc. Disabling the presentation of incoming HTML emails in your email client will close the most prominent way of attacking EFAIL. Note that there are other possible backchannels in email clients which are not related to HTML but these are more difficult to exploit.
I don't send HTML emails. Am I safe?
No. The attacker can change encrypted text/only emails to HTML emails. You need to disable viewing HTML email to increase protection from EFAIL attacks.I have disabled HTML in my email client. Am I safe now?
Depends. S/MIME or PGP encrypted emails are encrypted with the public keys of all recipients and the sender. The attacker can thus perform the EFAIL attacks if only one of the participants is vulnerable. In order to prevent the EFAIL attacks, all participants must use secure email clients.I have encrypted data using OpenPGP or S/MIME and I won't decrypt it in the email context. Am I safe?
For now yes. There may be edge cases though that we hadn't looked into. For example, if you encrypted a directory with sensitive files, an attacker could change these encrypted files to contain false information or even malware. If a victim decrypts the directory and opens any of the files, malware or even just an HTML file could be used to exfiltrate plaintext or even compromise the system.
I wonder if decrypting it to a non-executable folder would be prudent...
EDIT: I found this statement from the GnuPG and Gpg4Win developers. It asserts three points, which resonate some comments by users below, about the original release by EFAIL.de:
1. This paper is misnamed. It's not an attack on OpenPGP. It's an attack on broken email clients that ignore GnuPG's warnings and do silly things after being warned.
2. This attack targets buggy email clients. Correct use of the MDC completely prevents this attack. GnuPG has had MDC support since the summer of 2000.
3. The authors made a list of buggy email clients. It's worth looking over their list of email clients (found at the very end) to see if yours is vulnerable. But be careful, because it may not be accurate -- for example, Mailpile says they're not vulnerable, but the paper indicates Mailpile has some susceptibility.
The authors have done the community a good service by cataloguing buggy email email clients. We're grateful to them for that. We do wish, though, this thing had been handled with a little less hype. A whole lot of people got scared, and over very little.
In retrospect, for all the hype, I do wish that the overtone of some news articles were "check your email client," rather than "ditch PGP." In fact, that was part of the reason why I started this thread: to focus on preventable actions, because it is clear in the sources that the issue is only with certain clients.
Glad to hear you got it working I ran into a similar problem the first time I tried compiling a kernel.
gzip: stdout: No space left on device
I know this might sound crazy, but it might be failing because the build computer needs more storage space.
By the way, this tutorial explains how to also create .debs of the kernel. They can be installed with dpkg or gdebi (or backed-up in case of system failure/reinstallation) in other devuan systems of the same architecture.
https://debian-handbook.info/browse/sta … ation.html
None of the above -- I'm Ceres. To pochuye ke?
Do they need to be planets per se, how about moons Io and Europa?
The article seemed to imply that this factors into the way they categorize, so maybe.
So looking forward to next episode of 'The Expanse'.
Expanse characters would make for a great distro's release cycle naming schema.
https://www.sfgate.com/news/article/Yes … 893841.php
We find ourselves using the word planet to describe the largest "moons" in the solar system. Moon refers to the fact that they orbit around other worlds which themselves orbit our star, but when we discuss a world such as Saturn's Titan, which is larger than the planet Mercury, and has mountains, dunes and canyons, rivers, lakes and clouds, you will find us - in the literature and at our conferences - calling it a planet. This usage is not a mistake or a throwback. It is increasingly common in our profession and it is accurate...
Can't tell if it's a troll article or not, because if they are serious, there are a lot of other planets to consider for future Devuan releases
If you're using wicd, make sure your wifi interface is the same wireless interface in its settings.
You can list your network devices with ifconfig -a as root.
You can find your network card with lspci -vv | grep -i Network as root. For some devices, you may need proprietary/nonfree software.
Has there been any attacks/cracks reported due to these exploits yet?
I'm not aware of any publicly-disclosed information about successful attacks. I do find it interesting that all of these CVE's are coming from Google, at a time when the company is investing in ridiculous processors.
If you're concerned about your own system, have a look at this, which I'm sure is in the ASCII repos: https://packages.debian.org/stretch-bac … wn-checker
Glad to hear it. Hope you enjoy it
https://github.com/budgie-desktop/budgie-desktop
Reminds me a lot of cinnamon, but a nicer version. Or XFCE 4.12 (with all the conventional desktops based on GNOME, I still don't understand why xfce is trying to imitate them...). Can't say no to Rammstein, either.
I think it's promising that they plan to switch to Qt with version 11. Probably a better alternative since GNOME makes facepalm-worthy changes waaaaaay too often (eg, the "big tabs" problem in stretch/ascii). Wonder how it'll fare compared to lxqt...