The first CyanogenMod 13.0 release
We left the M release builds in the oven longer than we thought, but nothing a little graham cracker and chocolate can’t make that much better. CM13.0 brings Android 6.0.1 (r17) goodies such as the battery saving ‘doze’ functionality and new permissions model, alongside the CM features you’d expect." Other changes include the removal of WhisperPush, the removal of the "quick unlock" feature, a switch to the standard Android messaging app, a new "Snap" camera app, and more.
Posted Mar 16, 2016 8:50 UTC (Wed)
by xav (guest, #18536)
[Link] (44 responses)
Posted Mar 16, 2016 9:35 UTC (Wed)
by pabs (subscriber, #43278)
[Link]
https://wiki.debian.org/AndroidTools
I'm hoping it will go as far as Shashlik:
Posted Mar 16, 2016 9:36 UTC (Wed)
by pabs (subscriber, #43278)
[Link] (15 responses)
Posted Mar 16, 2016 10:18 UTC (Wed)
by xav (guest, #18536)
[Link] (14 responses)
Posted Mar 16, 2016 10:48 UTC (Wed)
by juliank (guest, #45896)
[Link] (13 responses)
Posted Mar 16, 2016 11:48 UTC (Wed)
by xav (guest, #18536)
[Link] (11 responses)
Posted Mar 16, 2016 12:21 UTC (Wed)
by dgm (subscriber, #49227)
[Link]
Posted Mar 16, 2016 15:40 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link] (2 responses)
X.509 certificates "chain" up towards a root. The certificate for replicant.us is a perfectly nice SHA-256 RSA signature by "CAcert Class 3 rRoot". Your browser does not trust "CAcert Class 3 Root" but a certificate for that is provided too, so the browser follows the chain. This certificate is a SHA-256 RSA signature too, signed by "CA Cert Signing Authority". Now, if your browser trusted CA Cert Signing Authority you'd be done. No further checks on CA Cert Signing Authority would be performed.
However your browser doesn't trust CA Cert Signing Authority, so it keeps going. There is a certificate provided for CA Cert Signing Authority, and that certificate too has a signature. It's signed by itself. That's fine for a root CA cert which is what this is. But, having been created in 2003 the signature uses MD5. MD5 is subject to a variety of known attacks, making it useless for signing certificates in the year 2016 and the browser disregards the whole certificate chain remarking SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED
Posted Mar 16, 2016 18:36 UTC (Wed)
by alvieboy (guest, #51617)
[Link] (1 responses)
Is this the certificate in question ? http://www.cacert.org/certs/root.txt
Alvie
Posted Mar 17, 2016 1:52 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link]
Comodo provides a nice tool crt.sh (and source for it if you'd rather run your own, click their github logo) which monitors the Certificate Transparency logs and shoves everything into a queryable database.
Everything crt.sh is showing is in some sense "in" the logs, but it is not the purpose of log servers themselves to offer arbitrary data mining, whereas a monitor can do whatever it likes.
CACert aren't obliged to log stuff, indeed nobody is actually _obliged_ to log their certificates except:
1. For any certs a CA wants given the EV (Extended Validation) treatment in which the certificate's country code and the organisation name are shown on a nice green bar, Chrome requires the cert to be in the logs on top of the other criteria. No logs? No green bar - pages still load, but given the green bar is the _whole point_ of spending hundreds of dollars and likely hours of employee time on an EV cert...
2. Symantec. Symantec inherited very old CA roots like Verisign and Thawte. Last year they managed to issue a laughably bogus cert. Google caught them and asked them to investigate. Symantec's "investigation" basically involved scapegoating an employee and claiming all was now well. So Google produced evidence of further problems and asked them to investigate _again_. But also, Google unilaterally demanded Symantec log absolutely every certificate or Chrome might start telling users Symantec's certs are bogus and that would ruin Symantec a long time before it'd hurt Google.
Everybody else is doing it voluntarily, at least in the same sense people voluntarily show their passports at immigration. In principle they do have a choice, but it seems pretty obvious what happens if they choose wrong.
Posted Mar 16, 2016 19:34 UTC (Wed)
by flussence (guest, #85566)
[Link] (6 responses)
Posted Mar 16, 2016 20:07 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
AES-CBC with HMAC-SHA1 is a perfectly OK cipher suite.
Posted Mar 16, 2016 20:08 UTC (Wed)
by juliank (guest, #45896)
[Link] (4 responses)
Posted Mar 16, 2016 20:11 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
HMAC in SSL is used only for transient hashes, it needs to be strong only for about 60 seconds (a typical connection timeout).
SHA-1 in certificates is bad because certificates stay valid for extended periods.
Posted Mar 16, 2016 21:42 UTC (Wed)
by juliank (guest, #45896)
[Link]
Posted Mar 17, 2016 7:41 UTC (Thu)
by Otus (subscriber, #67685)
[Link] (1 responses)
While that is true, it is not the main reason SHA-1 is bad in one instance and okay in another. It is because as a signature hash it allows collision attacks, while using it as a MAC or KDF only allows (second) preimage attacks.
Posted Mar 17, 2016 9:44 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Mar 16, 2016 15:28 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link]
The two big changes to the ecosystem are
1. The CA/B Forum and Baseline Requirements. The treadmill of ever lower standards (to capture lower price points for their certificates) was halted by the Baseline Requirements. A DV certificate from 2010 is a very poor thing, of dubious value in making any sort of trust decision. But the Baseline Requirements got rid of some of the most feeble CA policies like long arbitrary lists of "acceptable" contact email addresses for issuing certificates that you've never imagined would be used, so that I can have a bit more confidence in a modern certificate. And the forum that made those requirements has been able to gradually (slower than I'd like but still a huge improvement of the situation in the 1990s) ratchet up the security of the PKI
2. Certificate Transparency. Google's firm insistence on implementing this, regardless of the cries of CAs that it would be too expensive and too difficult and anyway wouldn't find any problems means we now have a very _good_ view of the remaining problems with the web's PKI. Actively malevolent CAs could of course hide naughtiness from CT until relying parties actually check the log proofs (Chrome does this only for EV so far), but we don't have any particular reason to think they're malevolent, just careless and perhaps greedy.
On top of this, CACert itself has seemingly ceased to be the ambitious group that wants to hold itself to higher standards than the for-profit CAs. It has become, if I am generous, a local German CA which doesn't like the expense of the traditional CA model. There's certainly no space to explain in your web browser "This site example.com is trusted because some Germans who are friends say it's fine". If you're one of those Germans, you should definitely add the CA root cert. But why would anybody else?
CACert's members were very vocal early in its life about how little actual value the relying parties get from the CAs. And probably if they'd come up with a model that did deliver value to relying parties, the CA/B Forum would never have happened and we'd be having a very different discussion. But they never did that. So the situation today is that relying parties continue to not get much value from CAs but we did manage to eliminate the cost (both financial and in labour terms) of maintaining DV certs which was, if we're honest, one of the big attractions of CACert.
Realistically then, Replicant should just get itself a Let's Encrypt cert.
Posted Mar 16, 2016 16:45 UTC (Wed)
by torquay (guest, #92428)
[Link] (26 responses)
Posted Mar 16, 2016 18:14 UTC (Wed)
by pizza (subscriber, #46)
[Link] (19 responses)
As long as you stick to Dalvik applications, then Android has decent (but by no means perfect) backwards compatibility. At the NDK (ie native) layer, things get much, much messier.
> Fedora is even worse in that regard, where you can't expect stability even within one release: the most recent example is the deliberate introduction of a regression into its kernel.
Putting aside the fact that this is actually an upstream kernel problem, not something unique to Fedora..
...How dare Fedora disable a kludgy workaround to get audio out of a known-problematic laptop, when said workaround introduces regressions (of the failure-to-boot variety) on other systems.
Posted Mar 17, 2016 3:11 UTC (Thu)
by torquay (guest, #92428)
[Link] (18 responses)
Audio worked, on a widely used laptop. Now it doesn't. It's a regression, pure and simple. This kind of cowboy crap wouldn't fly in the RHEL world, so why should it in Fedora? Arguing otherwise is just an indication that RH treats Fedora users with zero respect.
Posted Mar 17, 2016 12:27 UTC (Thu)
by pizza (subscriber, #46)
[Link] (17 responses)
No, out of the box Fedora *didn't work*, a kludge was introduced with a later update that worked, but turned out to cause other problems elsewhere. Pop quiz, which regression is more serious; a single laptop's audio not working, or multiple other systems not even booting?
(Again, this is an upstream kernel problem, affecting *all* users of that kernel and that particular hardware)
> This kind of cowboy crap wouldn't fly in the RHEL world,
In the RHEL world you explicitly buy hardware that's already been certified to work with that particular OS, intending to run software that's also been certified for that particular OS, instead of "cowboying" it with a brand-new bit of kit and installing a bleeding-edge, unsupported OS on it that doesn't work out-of-the-box.
> Arguing otherwise is just an indication that RH treats Fedora users with zero respect.
s/RH/Dell/ -- After all, it's their hardware, and they're the ones who botched the ACPI/firmware implementation badly enough such that after 7 updates the audio still doesn't work properly without lying to the laptop about what ACPI features are supported.
Posted Mar 17, 2016 13:07 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (4 responses)
The code in question is gated behind a DMI check that only runs on the specific laptop. How could it cause problems elsewhere?
Posted Mar 17, 2016 13:48 UTC (Thu)
by pizza (subscriber, #46)
[Link] (3 responses)
But I will quote Comment 14 on that RHBZ #1313434:
"FYI, CONFIG_ACPI_REV_OVERRIDE_POSSIBLE causes the 32-bit kernel to reboot
Which seems like a more serious problem than not having sound.
Posted Mar 17, 2016 14:38 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
Yes.
> "FYI, CONFIG_ACPI_REV_OVERRIDE_POSSIBLE causes the 32-bit kernel to reboot
I'd be pretty amazingly astonished if this is true, since the only thing the code does is set a flag that causes the kernel to revert to its <4.2 behaviour.
Posted Mar 17, 2016 16:09 UTC (Thu)
by raven667 (subscriber, #5198)
[Link] (1 responses)
I find this amusing that you'd be astonished by any hardware foolishness after staring in the gaping abyss of low level boot code for so long.
Posted Mar 17, 2016 19:44 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link]
Posted Mar 17, 2016 15:09 UTC (Thu)
by torquay (guest, #92428)
[Link] (11 responses)
Audio in Fedora 22 worked fine. Fedora 23 out-of-the box introduced the first regression (ie. F22 -> F23 upgrade), which was (promptly) corrected. Most recently the workaround for the audio setting was accidentally removed during the kernel 4.3 -> 4.4 update within F23, causing the second regression. Upon being informed of this, Abbott re-enabled the workaround, but then deliberately removed it. This is certainly cowboy behavior.
Posted Mar 17, 2016 15:42 UTC (Thu)
by peter-b (guest, #66996)
[Link] (2 responses)
Posted Mar 17, 2016 15:57 UTC (Thu)
by torquay (guest, #92428)
[Link] (1 responses)
Posted Mar 18, 2016 15:04 UTC (Fri)
by clump (subscriber, #27801)
[Link]
Posted Mar 17, 2016 15:44 UTC (Thu)
by pizza (subscriber, #46)
[Link] (6 responses)
Not out-of-the-box it didn't. The laptop needed a firmware update (actually, several) in order to get to that point. (Seriously, that laptop was a complete basket case on Linux for a while -- which is why I decided against buying it)
Well, unless you bought the "XPS 13 developer edition" and stuck to the OS/Kernel that shipped with the system instead of updating to upstream Ubuntu. But even the developer edition (and the firmware fixes that made it possible) came well after the laptop was available to the general public.
> One can argue ad infinitum that this is "upstream's fault", continually passing the blame. In the end, audio with the Fedora kernel worked, and then it was deliberately broken. From the point of view of Fedora users, the Fedora kernel is the upstream. You break it, you fix it.
You're right, this particular regression is technically the Fedora kernel maintainer's fault.
I suggest you contact your official Fedora support rep about this breach of contract. You're probably entitled to a full refund.
Posted Mar 17, 2016 16:13 UTC (Thu)
by raven667 (subscriber, #5198)
[Link] (1 responses)
I understand that people don't like being criticized for their decisions but I think this is all in the spirit of making the software better, not just blaming and pointless venting.
Posted Mar 17, 2016 20:33 UTC (Thu)
by pizza (subscriber, #46)
[Link]
Today's "On the Fastrack" seems quite appropriate:
Posted Mar 17, 2016 19:43 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (1 responses)
Yes it did.
Posted Mar 21, 2016 18:25 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Mar 20, 2016 21:39 UTC (Sun)
by tuna (guest, #44480)
[Link] (1 responses)
If you have specific HW that does not work Fedora does not really care in my experience. But I do not know if any free (as in cost) distro is better.
Posted Mar 20, 2016 21:42 UTC (Sun)
by tuna (guest, #44480)
[Link]
Posted Mar 25, 2016 10:46 UTC (Fri)
by darkbasic (guest, #107872)
[Link]
@whoever jokes about asking refunds for FOSS software
Regarding Android: it is utter shit compared to whichever Linux distribution. ABI compatibility means nothing to me if they keep the development behind the curtains, with giant patchsets you will never be able to merge upstream and ugly blobs all over around. I'm angry enough because of the Intel's firmware, wishing to transform Linux to an Android-like nightmare is out of question.
P.S.
Posted Mar 17, 2016 0:30 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (5 responses)
Google sure gets points for making it a successful business with large following and deployment numbers. However, Android is a new Unix: fragmented, ridden with proprietary crap, mostly unpatched, full of security holes on deployed systems, unupgradeable depending on hardware etc.
What Google are doing with Android is not open source. It's based on open source, but then it's more like dump source. They have a tendency to just do whatever they like and mostly refuse to cooperate with anyone. That's not very serious.
Posted Mar 17, 2016 0:45 UTC (Thu)
by Garak (guest, #99377)
[Link] (2 responses)
Posted Mar 17, 2016 1:29 UTC (Thu)
by bojan (subscriber, #14302)
[Link]
Posted Mar 18, 2016 12:31 UTC (Fri)
by andy0 (guest, #107558)
[Link]
Posted Mar 17, 2016 3:05 UTC (Thu)
by torquay (guest, #92428)
[Link] (1 responses)
And the plethora of Linux-based Unix-like OSes (distros) is any better? I'd argue that having a bazillion Linux distros is actually far worse: you can't rely on any particular library version being present, and there is zero guarantee of binary compatibility between distros. With Android you know what to expect, based purely on the API level.
Posted Mar 17, 2016 5:54 UTC (Thu)
by bojan (subscriber, #14302)
[Link]
At least with most (if not all) Linux distros you can see what they are doing, because all the development is right there in the open.
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
Yes you're right the certificate is good, it's the web server which is not configured properly:
The first CyanogenMod 13.0 release
www.replicant.us uses an invalid security certificate.
Which doesn't look very serious to me.
The certificate is not trusted because it was signed using a signature algorithm that was disabled because that algorithm is not secure.
Error code:
SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED
The first CyanogenMod 13.0 release
MD5
MD5
MD5
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
I would love to have an Android distribution with all the seriousness we are accustomed to see in classical Linux ones, a Debian/Fedora for Android.
I think it might be more appropriate the other way around: a Fedora/Debian with the seriousness of Android. Android cares about API and ABI stability from one release to the next. Fedora and Debian do not. Fedora is even worse in that regard, where you can't expect stability even within one release: the most recent example is the deliberate introduction of a regression into its kernel.
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
...How dare Fedora disable a kludgy workaround to get audio out of a known-problematic laptop, when said workaround introduces regressions (of the failure-to-boot variety) on other systems.
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
as soon as the 32-bit kernel boots."
The first CyanogenMod 13.0 release
as soon as the 32-bit kernel boots."
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
No, out of the box Fedora *didn't work*, a kludge was introduced with a later update that worked
which regression is more serious; a single laptop's audio not working, or multiple other systems not even booting?
This particular workaround for the audio setting is only enabled on the laptop in question.
s/RH/Dell/ -- After all, it's their hardware, and they're the ones who botched the ACPI/firmware implementation badly enough such that after 7 updates the audio still doesn't work properly without lying to the laptop about what ACPI features are supported.
One can argue ad infinitum that this is "upstream's fault", continually passing the blame. In the end, audio with the Fedora kernel worked, and then it was deliberately broken. From the point of view of Fedora users, the Fedora kernel is the upstream. You break it, you fix it.
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
How much do you pay for your Fedora subscription, by the way?
I pay with my time by testing Fedora and filing bugs in the Red Hat Bugzilla. In turn, Red Hat indirectly uses my time and efforts to build RHEL, its bread and butter.
The first CyanogenMod 13.0 release
I pay with my time by testing Fedora and filing bugs in the Red Hat Bugzilla. In turn, Red Hat indirectly uses my time and efforts to build RHEL, its bread and butter.
It's good that you contribute, however if you think of Fedora as "free RHEL testing" you'll grow resentful. Fedora is RHEL's upstream, but it is a distinct project.
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
Wol
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
https://bugzilla.redhat.com/show_bug.cgi?id=1240566
The first CyanogenMod 13.0 release
You're not funny, free doesn't mean low quality nor having to settle. I personally contribute in many ways besides throwing a fixed amount of money at FOSS projects every month and there are plenty of peoples who contribute even more. I have no interest in the Fedora kernel because I always compile my own, but still I keep reporting bugs on configuration issues because I want things to work out of the box for other peoples.
The real one to blame here is Dell, because this fucking laptop is supposed to support Linux while the only thing which it does (half) support is their Android-like outdated Ubuntu distribution. You cannot sell a "Linux" laptop and at the same time ignore issues like this: https://bugzilla.kernel.org/show_bug.cgi?id=105251
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
The first CyanogenMod 13.0 release
Android is a new Unix: fragmented,
The first CyanogenMod 13.0 release