It has been about 6 months since we last released a batch of images. A few things of interest were completed in the meantime, so we are rolling out new images today.
This release doesn’t bring support for any new device: instead, it mostly contains stability fixes for the devices we already support. The most considerable change in this release is the inclusion of the Samsung-RIL rewrite, that was developed this summer. Samsung-RIL is the component in charge of dealing with the modem, the hardware chip that communicates with the mobile telephony network. The code that was used since then didn’t have a good structure and didn’t meet the code quality standards required to call it stable or reliable. The rewrite should be more robust and fail-proof: it has been tested daily on a couple of devices for the past few months, with no major incident to report. The Samsung-RIL rewrite has about as many features supported as the previous version, with the exception of a few ones that were broken anyway (mainly, USSD and STK).
The new code establishes a sane basis for external contributions, so everyone is welcome to dig in and add support for what’s missing.
Another big achievement in that release is the inclusion of about a dozen security fixes, covering issues such as Shellshock, Master key, Fake ID and much more, thanks to reports by community members.
As usual, you can checkout the complete changelog, download the images from the ReplicantImages page and find installation instructions as well as build guides on the Replicant wiki.
Even though this release doesn’t introduce support for any new device, I have been at work regarding devices that make the best candidates for freedom and privacy/security. As mentioned in an earlier post, we are going to focus the development effort on a few devices that allow running free bootloaders and are either likely to have good modem isolation or don’t have a modem at all.
Recently, I have been working on adding Replicant support for Sunxi devices. There is a lot of work to do in that area and while nothing was released yet, it looks promising. I also spent a considerable amount of time working on the LG Optimus Black (P970)’s bootloader. I will be posting a series of articles about what an incredible journey it has been so far on my personal blog over the next few days. Eventually, the device will be properly documented in our wiki and as soon as U-Boot reaches feature completeness, it will be time to start porting Replicant to the device!
December 20th update: The full series of articles about freeing the LG Optimus Black (P970) is now available:
Of course, improvements to the wiki are welcome, but it’s not publicly open for edits. You can either ask for wiki editor rights (send me an email to do so) or just send a diff of the changes you suggest to the mailing list for review!
It looks like the key combination is right in the page. As for mentioning administrative rights, it should probably be indicated in http://redmine.replicant.us/projects/replicant/wiki/ToolsInstallation
Hi Paul,
I have recently installed Replicant 4.2 0003 on Samsung Galaxy SII (I9100). The experience is comparable to the default Android 4.1 on that device.
While installing I have found some of the instructions in the installation manuals needs an edit, for example, heimdall requires an adminitrative privilage to access the device (sudo or su for Debian GNU/Linux based distributions) and the keycombination to unlock is the Power button+Volume down rocker button+Home button.
Where am I supposed to send these edits?
This is my first post in replicant so my apologies for any mistakes.
It’s moving forward, very slowly, due to the ever-shrinking amount of time that I have at disposal. Replicant will not be ready for FOSDEM on either the Optimus Black or Sunxi tablets, but there will certainly be some demos there!
How’s your work on the LG Optimus Black and Sunzi tablets going? Will you have them ready for FOSDEM do you think?
> I’m glad you like the idea. I know it wouldn’t be the same level of authenticating as verifying with you in person, but couldn’t you create a certificate fingerprint statement like this? https://help.riseup.net/security/network-security/certificates/riseup-signed-certificate-fingerprints.txt
I made a note of it, I’ll look into it at some point.
> That way, people could verify the fingerprint statement using GPG and see if anyone in their web of trust has signed it, correct?
Yes, that would indeed work
> Also, I really like the idea of linking to HTTPS by default for the whole site. Maybe the site could first go to an HTTP page that explains the specific situation with Replicant.US and SSL for n00bs, since your SSL situation is set up a bit different than how other sites do it. Example: http://www.parabola.nu/https/ Then the rest of the site could be encrypted via SSL.
I don’t really see a problem with keeping an http access available as well as https. If people think they want their communications with the website encrypted, they’re welcome to switch to https. Why not keep both?
I’m glad you like the idea. I know it wouldn’t be the same level of authenticating as verifying with you in person, but couldn’t you create a certificate fingerprint statement like this? https://help.riseup.net/security/network-security/certificates/riseup-signed-certificate-fingerprints.txt
That way, people could verify the fingerprint statement using GPG and see if anyone in their web of trust has signed it, correct?
Also, I really like the idea of linking to HTTPS by default for the whole site. Maybe the site could first go to an HTTP page that explains the specific situation with Replicant.US and SSL for n00bs, since your SSL situation is set up a bit different than how other sites do it. Example: http://www.parabola.nu/https/ Then the rest of the site could be encrypted via SSL.
Encrypt all the things!
That’s a good idea, we could have a wiki page about that. However, just like our GPG key for releases, this is only really valid if you get to verify the key fingerprint with us in person.
That’s right. I like to use the “//” thing instead of “http://” or “https://” so that it stays with the currently-used protocol, but this doesn’t work for RSS feeds (readers see that as a local address, which makes sense). Perhaps linking to https as default is the best idea.
Can you please write a blog or post a link promently somewhere on the main page about how to verify your SSL Cert?
Something like this perhaps: https://help.riseup.net/en/security/network-security/certificates
Also, when using HTTPS on your main page, many of the links on your website link to HTTP, so this forces your users to manually add the S after copying and pasting the address of many of the internal links on your site. For instance, clicking the link to this very blog from the HTTPS version of the Homepage would cause one to lose one’s encrypted connection to your website if not paying very close attention.
Sure, I’m going to be at FOSDEM, hopefully with one talk or more to present (no stand though). I may have things to show regarding both the Optimus Black (P970) and Sunxi devices.
Thanks for your support, that’s good motivation fuel!
Very exciting! That’s coming up pretty quick. Are you talking at FOSDEM this year? I’m watching this video from last year now: http://ftp.osuosl.org/pub/fosdem//2014/K1105/Sunday/ARM_Allwinner_sunxi_SoCs_and_the_community_behind_it.webm
I really hope that whatever it is that isn’t looking so good gets worked out. I predict that Replicant support for these devices will be a game changer. Keep up this important work Paul! Tons of people out here support you very much and are very appreciative of what you are doing.
Thank you, Paul & Co.! Go on, please.
It really depends on how much work I can manage to get done. Things are not looking so good these days, but I’m hoping to have basic Replicant support available and pushed for FOSDEM.
Do you happen to have even a really rough estimate as to when the Sunxi device images will be released? Will it be within the next 6 months?