You are not logged in.
- Topics: Active | Unanswered
#201 Re: DIY » The hunt for a good browser 2017 edition » 2018-05-09 14:39:56
It is light, isn't it!
Quite light. It compiles in less than a minute on my systems. The patches are excellent too 
https://surf.suckless.org/patches/
#202 Re: Devuan Derivatives » crunkbong is looking for testers » 2018-05-09 13:28:19
If your still looking for testers, I got a partition empty.
A dell laptop, amd64. No 32bit in the house, sry.
Thanks! crunkbong is currently 64-bit only, so that sounds perfect. Let me know what you think 
#203 Re: Devuan Derivatives » crunkbong is looking for testers » 2018-05-09 12:49:41
crunkbong 0.7.10 is ready!
https://sourceforge.net/projects/crunkb … p_redirect
Changelog, 5/09/2018:
-Updated kernel. The jessie-security kernel is now replaced with liquorix 4.16. The kernel is not only debloated, but also uses the actual KPTI patches, which mitigate recent microcode exploits, rather than the ones backported for jessie/jessie and ascii/stretch (kernels< 4.14.14). Once crunkbong migrates to Devuan ASCII, I will consider if it's best to continue using liquorix, or just the ascii-backports kernel, least of all because it bumped the image size by about 40mb. Also, thanks to fsmithred (again) for help in using recent kernels in jessie
-Added tcptrack. top-like network monitor. Unlike its alternatives, instead of keeping a log of all the connections, it'll just show information in realtime, and discard it after the connection closes.
-Switched wiki. I like Github's better than SF's. https://github.com/souperdoupe/crunkbong/wiki
#204 Re: DIY » The hunt for a good browser 2017 edition » 2018-05-08 13:02:21
It's an excellent browser. I suppose one's biggest gripe might be against WebKit's periodic exploitation.
https://www.blackhat.com/docs/eu-14/mat … Not-WP.pdf
https://github.com/Cryptogenic/Exploit- … rite-up.md
All things considered, though, I prefer it over pretty much every other browser. It's sensible, lightweight, and portable. Why is that so difficult to find in a browser these days?
#205 Re: DIY » The hunt for a good browser 2017 edition » 2018-05-08 12:20:13
Just an FYI, Firefox versions 56+ leak the browser's buildId: you can test it here. This value is one way the NSA is able to identify browsers, including Tor, so as to implement exploits like FOXACID/QUANTUMINSERT. The about:config value general.buildId.override is "supposed" to override it, but doesn't. This kinda sucks because so many legitimate addons are built as WebExtensions now, so falling back to esr/palemooon is really a longer temporary solution.
I'm surprised surf isn't gaining more recognition.
#206 Re: Devuan » Microcode exploits thread - spectre, meltdown, the list goes on... » 2018-05-07 16:36:11
Thank you. I updated the original posting.
#207 Devuan » Microcode exploits thread - spectre, meltdown, the list goes on... » 2018-05-07 13:24:20
- siva
- Replies: 11
I take a personal interest in computer/network security; it's integral to my technology philosophy. Back in January, during the initial microcode pandemonium, Schneier said, "more [exploits] are coming, and they'll be worse. 2018 will be the year of microprocessor vulnerabilities, and it's going to be a wild ride." I intend to follow this claim as 2018 continues, and then look back to evaluate steps taken by vendors, along with lessons learned (versus lessons that were documented and ignored by users and vendors alike), and new best practices for modern computing. I am particularly interested to discover the degree to which these exploits change the way we use technology, along with implications for the "Internet of Things" (also criticized in the Schneier article).
I thought it might be fruitful to dedicate a thread to microcode-based exploits, since the fundamental nature of them resides in modern processor design. Feel free to share knowledge, papers, thoughts, and the like.
Backstory: Many of these recent exploits have a long history of x86 infrastructure errors being ignored. Lots are documented under the KPTI/x86 section of this website entry. Two articles in particular are of interest: one from 1995 and another from 2015. The 2015 blog post, "x86 is a high-level language", notes a foreboding conclusion:
"...any attempt to get smooth, predictable execution out of the processor is very difficult. That means "side-channel" attacks on x86 leaking software crypto secrets may always be with us..."
This insight brings into question the entire framework of some Linux users: the use of older hardware. The warning, back in 1995, is clear: be wary of x86. Server admins, lend an ear.
Two decades of pretext lent itself to another 2015 article, also mentioned in the Cromwell link, titled "Intel x86 is considered harmful." Its introduction leaves a notable question:
This raises an interesting question: once we realize firmware, and (some) hardware, should be treated as untrusted, can we still build secure, trustworthy computer systems?
Three years later, admins everywhere were forced to give answer.
January: The two big players back in November 2017 - January 2018 were Meltdown and Spectre (variants 1 and 2). Some important findings were that Spectre remains unpatched and a threat to all modern processors, and the Meltdown patches (KPTI), avialable on amd64 kernels 4.14.14+ (and backported to older debian kernel versions), might not ever be available for i386. (This came straight from the patch developers).
Not long after, a website claimed the unveiling of two new speculative exploits: skyfall and solace. Neither exploit is documented, and both have been disregarded as hoaxes or trolls. Not to say they died without merit, however: the nonexistent attacks served as a warning to anyone who bandwagons news stories without researching their credibility -- perhaps a human form of speculative exploit.
February: Another set of exploits, MeltdownPrime and SpectrePrime, were also unveiled. One finding (from the abstract) is of particular note:
As a proof of concept, we implemented SpectrePrime as a C program and ran it on an Intel x86 processor. Averaged over 100 runs, we observed SpectrePrime to achieve the same average accuracy as Spectre on the same hardware—97.9% for Spectre and 99.95% for SpectrePrime.
In short, to support the findings above, and KPTI developer claims, x86 is quite vulnerable. I have been told that x86's design flaws is "old news." Nevertheless, here are modern examples. (In the paper, I did not see any tests on x86_64 hardware.)
May: This past Saturday, there were also reports of a Spectre-NG. The source of these findings roots back to the German website Heise.de. (I don't know much about the credibility of this source, as I am unfamiliar with it.) The author of the Tom's Hardware article on the topic reached out to Intel and received no response, presumably because Google Project Zero gives vendors a 90-day head start before releasing information. According to the Heise article, Linux developers are aware and working on the exploit. Intel patches may remain vulnerable until as late as August 2018.
#208 Re: Installation » SOLVED - chroot live build - kernel panic » 2018-05-06 20:02:54
My hero
Those two packages did the trick. Also, it turns out they were compiled alongside live-boot and live-config -- they were residing in the same directory as the compiled debs. So, backporting live-boot/config built them, and all I had to do was install them. Shame on me for not checking the other debs that were originally created and should have been installed lol.
Problem solved -- even works with the newest liquorix kernel.
#209 Re: Devuan Derivatives » [NEW]-FluXuan Linux-[RELEASE] » 2018-05-05 22:19:47
I am trying to figure out where is the relation to FluXuan in all the latest POSTS !
I think it'd be a great idea to make a wiki for your project. I'd be interested in reading it.
#210 Re: Installation » SOLVED - chroot live build - kernel panic » 2018-05-05 22:07:57
still complaining about ehci-orion not being in modules.dep
It always says that when there's a problem.
Why does it give that particular message? It seems way too vague.
What was in conf/conf.d/ in the initrd? That's usually where the problem is.
The folder conf contains two files and one folder:
arch.conf contains one line: DPKG_ARCH=amd64
conf.d is completely empty.
I uploaded initramfs.conf to pastebin. Not really sure what any issue would be...
https://pastebin.com/ChjY6Kzm
Edit: I compared it with the jessie (3.16) initrd.img. The results were exactly the same, including the contents of conf.d and initramfs.conf.
#211 Re: Installation » SOLVED - chroot live build - kernel panic » 2018-05-05 18:43:37
Well, I manually backported both of them, and that solved the first chunk of problems.
https://github.com/souperdoupe/crunkbon … -backports
Sadly, it's still complaining about ehci-orion not being in modules.dep. I'm not sure if this can/should be patched or if it's available in some other package.
https://ibb.co/h9o2yn
The 3.16 modules.dep file doesn't contain ehci-orion at all, either, but it doesn't err. This seems to be an issue that keeps popping up with the 4.9+ kernels.
#212 Re: Devuan Derivatives » [MiyoLinux] New Releases Uploaded » 2018-05-04 22:56:11
The "login screen" is either slim or lightdm, iirc. you can use ps -ax | grep [slim, lightdm] if you aren't sure, read the manpages, and possibly do further reading/googling, to find out how to customize it to your needs, or if you'll want to use another desktop manager altogether.
Typically, it's considered good security practice to not provide a username directly on a lock or login screen.
#213 Re: Off-topic » In what country are you right Now ? » 2018-05-04 13:25:31
Live in the US, don't call any particular place home. Lived good deal of my life in the Pacific, Marianas and Hawaii. Born in Tennessee, Texas is where much of my family reside.
...
@siva: Could be the US with your riddle. For reference: New Madrid Seismic Zone, San Andreas, and Yellowstone National Park potential super volcano.
Don't forget Florida, which is soon to become the new Atlantis. 
#214 Re: Installation » SOLVED - chroot live build - kernel panic » 2018-05-04 13:22:46
There's no more aufs in the kernel (4.9 or 4.14)
That's the gist I got :\
You may need a newer version of live-boot* and live-config*. 20170112 should work (works for me) and is in ascii.
Thanks, I noticed that jessie's versions are considerably older, live-config in particular. I'll try the live-build backport just in case. If it still fails, and manually backporting isn't worth it, I'll just consider upgrading to ascii sooner than anticipated.
If you have a union=aufs (or union=anything) in your boot command, remove it.
There is no union=* in the boot command. A few sites suggested to try union=overlay, which I tried, but that failed.
#215 Re: Installation » SOLVED - chroot live build - kernel panic » 2018-05-04 01:42:27
I checked everything and nothing seemed weird. I also removed both kernels and reinstalled the bpo amd64. However, this recent build is giving some weird issue about aufs:
https://preview.ibb.co/m4CsB7/Screensho … _04_AM.png
This bug report suggested that the post-jessie kernels no longer use aufs, and have replaced it with overlayfs. It didn't offer a real solution, though.
https://bugs.debian.org/cgi-bin/bugrepo … =844749#30
sed -i "s/LB_UNION_FILESYSTEM=\"aufs\"/LB_UNION_FILESYSTEM=\"overlay\"/g" config/chroot
where config/chroot is an ambiguous directory, which is unhelpful.
I find this weird because I can run the backported kernel on my build system (devuan jessie) just fine.
#216 Re: Desktop and Multimedia » cannot get VLC hardware acceleration under Ascii/Raspberry Pi 3 » 2018-05-04 00:00:01
Sorry, I misinterpreted what you meant. I don't think you're derailing the thread; your comment provided a legitimate solution. And I stand by my advice. ^_^
#217 Re: Desktop and Multimedia » cannot get VLC hardware acceleration under Ascii/Raspberry Pi 3 » 2018-05-03 19:56:32
i'd probably keep hosting my packages at a custom repo anyways unless there is a huge demand
If you believe it's worth sharing and people will benefit, then share it.
My experience with Linux is that there are a lot of small projects people have that go unadvertised, so people end up basically recreating it, because they have no idea that someone already made it.
I think it would also be worthwhile posting your query on the Raspberry Pi forums, since arm64 is your target architecture.
#218 Re: Devuan Derivatives » [NEW]-FluXuan Linux-[RELEASE] » 2018-05-03 12:48:32
what should i do
Document your processes.
#219 Re: Devuan Derivatives » [NEW]-FluXuan Linux-[RELEASE] » 2018-05-03 12:33:57
never seen 50MB yet on x64.
Presumably because x64 assumes the system is using >=4gb of ram, and that the extra 50mb won't matter.
On an 8gb system, my distro boots somewhere between 75-90mb before X is launched, and about 105-110 with X running. On a 1gb qemu vm, it's somewhere around 60-75mb without X.
#220 Re: Off-topic » In what country are you right Now ? » 2018-05-03 12:28:31
Fun facts: in the future, most of my country will explode, and another part will be submerged underwater, all due to purely natural causes.
Which country am I in?
#221 Re: Devuan Derivatives » [Miyo] How to set daily trim job? [SOLVED] » 2018-05-02 18:03:52
the || true is not only superfluous, it can potentially be misleading
My guess is that Mint chains the output to some other command or logger, or as you said, to keep the anacron job going without pause, but at the cost of not knowing that your fstrim failed or why. Couldn't say for sure, though.
@Ron: I'm glad you solved your task. Linux has a lot of options and ways to approach problems. It looks like you found one that works for your needs. Never stop learning
#222 Re: Devuan Derivatives » [Miyo] How to set daily trim job? [SOLVED] » 2018-05-02 01:27:05
Looks like you've made your first cron job
Some final thoughts:
1. anacron should have its own service that can be managed with the "service" command. Example: service anacron restart can be used in lieu of rebooting your entire system. This is true of many services: service --status-all
2. I really want to know why your anacrontab doesn't read:
1 8 automatic.trim /sbin/fstrim --all || true
Also, what's the rationale behind keeping the " || true" statement?
#223 Re: Devuan Derivatives » [Miyo] How to set daily trim job? [SOLVED] » 2018-05-02 00:56:34
I prefer to have my scripts be their own separate jobs, because then they get their own separate timestamp file in /var/spool/anacron/ and things are a bit more explicit.
Wouldn't the --verbose flag achieve the same result?
https://man.cx/run-parts(8)
Scratch that, I see what you meant.
#224 Re: Devuan Derivatives » [Miyo] How to set daily trim job? [SOLVED] » 2018-05-02 00:45:56
Here are some follow-up questions for you to consider:
How can you check if your script is in cron.daily?
What is the syntax for anacrontab?
How can you determine if anacron is running scripts?
How can you determine if anacron has ran your script?
If you can answer these, you'll probably be able to figure out your question.
Best of luck.
#225 Re: Devuan Derivatives » [Miyo] Kernel questions » 2018-05-02 00:31:14
It's probably the reptile overlords updating the reality simulator again. Not your fault.
The CVE tracker has outlined the vulnerable and patched versions for a few months, and it looks like it hasn't changed.
https://security-tracker.debian.org/tra … -2017-5754
The only claims for invulnerability I've heard are hardware-level exceptions.
Board footer
