Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking: upstream reconsidering signature spoofing #575

Closed
TinfoilSubmarine opened this issue Feb 21, 2024 · 34 comments
Closed

Tracking: upstream reconsidering signature spoofing #575

TinfoilSubmarine opened this issue Feb 21, 2024 · 34 comments

Comments

@TinfoilSubmarine
Copy link

Just saw this, not sure what involvement you guys have so figured I would point it out here:

https://review.lineageos.org/q/topic:%22microg-eval%22

@TinfoilSubmarine TinfoilSubmarine changed the title Tracking: upstream reconsidering signature spoofing? Tracking: upstream reconsidering signature spoofing Feb 21, 2024
@ArchangeGabriel
Copy link

Great news there. Hopefully it gets merged. :)

@petefoth
Copy link
Contributor

Thanks. I was sceptical, but it seems there's been a genuine change of heart, which is great.

On a practical note, I don't know gerrit: how can I find out when the changes are going to be (or have been) merged? I suspect the changes will break our builds, since applying patches to files that don;t need them isn't going to end well :)

Luckily, applying the patches in now 'switchable' - see Make the operations performed by the docker image 'switchable' #508, and those changes got merged to our master branch by mistake 😄 I just need to know when to switch that operation off

@TinfoilSubmarine
Copy link
Author

It will say "Merged" on the bottom right corner where the status is. I'll keep an eye on it and report back here. I think you might be able to CC yourself, but you'd need to log into Gerrit (via Google SSO) to do that.

@st3rox
Copy link

st3rox commented Feb 22, 2024

Joined their discord server to ask, they even have it in the server rules not to ask for signature spoofing, so this is very strange

Edit: wonder if you guys will get a public apology for all the extra time and money spent for no reason 🤣

@ArchangeGabriel
Copy link

I think there is renewed interest because a major brand, Huawei, started to use microG, and also /e/ is gaining traction. microG has been receiving a lot of code contributions lately, from both /e/ and Huawei, which likely made the project more “serious” (i.e. not relying on only one person that had gap of contributions).

@st3rox
Copy link

st3rox commented Feb 22, 2024

I think there is renewed interest because a major brand, Huawei, started to use microG, and also /e/ is gaining traction. microG has been receiving a lot of code contributions lately, from both /e/ and Huawei, which likely made the project more “serious” (i.e. not relying on only one person that had gap of contributions).

Last I saw, they refused to enable signature spoofing because they claimed it was a security risk

Now it's not I guess

@ghost
Copy link

ghost commented Feb 22, 2024

Joined their discord server to ask, they even have it in the server rules not to ask for signature spoofing, so this is very strange

Edit: wonder if you guys will get a public apology for all the extra time and money spent for no reason 🤣

questions like that just waste developer time.
will be answered later.

https://review.lineageos.org/c/LineageOS/lineage_wiki/+/383751

I think there is renewed interest because a major brand, Huawei, started to use microG, and also /e/ is gaining traction. microG has been receiving a lot of code contributions lately, from both /e/ and Huawei, which likely made the project more “serious” (i.e. not relying on only one person that had gap of contributions).

or because they are frustrated because Google blacklisted the fingerprints used on ih8sn.
assuming that Lukaz is the one who created ih8sn and who made this microg proposal.

@petefoth
Copy link
Contributor

I'll keep an eye on it and report back here.

Thank you. I'll try and keep an eye on it too, but I may miss something.

I think you might be able to CC yourself, but you'd need to log into Gerrit (via Google SSO) to do that.

I've done that. All of the changes in the topic involve changes to frameworks/base, so I'm watching the android_frameworks_base github repo and I should get any email if there are any changes.

Joined their discord server to ask, they even have it in the server rules not to ask for signature spoofing, so this is very strange

I have looked there, but the channels are pretty noisy, and the atmosphere is pretty toxic (Comments from the maintainers like "that patch is kinda shite"). I will keepmy eye on it, but I don;t have alot of time to waste spend there

@st3rox

This comment was marked as off-topic.

@petefoth

This comment was marked as off-topic.

@petefoth
Copy link
Contributor

I suspect the changes will break our builds, since applying patches to files that don't need them isn't going to end well :)

Luckily, applying the patches in now 'switchable' - see Make the operations performed by the docker image 'switchable' #508, and those changes got merged to our master branch by mistake 😄 I just need to know when to switch that operation off

I may keep the patches anyway: they would be needed if users of our docker build engine wish to include apps other than microG which do signature spoofing. From a brief look at the proposed changes, I think that the upstream changes and our patches can coexist, but I'll need to do some testing.

@stuart-nolan
Copy link

stuart-nolan commented Feb 23, 2024

and the atmosphere is pretty toxic (Comments from the maintainers like "that patch is kinda shite").

FWIW that comment, made in irc and relayed to discord, is likely in response to an issue not related to microg in any way. The patch to which it does refer to has not been merged into lineageos and there are critical comments about it by others. While I think it is less than diplomatic phrasing, it is also concise, consistent with irc etiquette, and was helpful to me to know that other devs find that patch unpalatable.

More on topic for this issue, the lineageos microg patch is specific to userdebug/eng builds. The lineageos microg patch can be easily modified for "user" builds; however, for people doing manual user builds with lineageos4microg (me for one) should this limitation be mentioned/flagged?

@petefoth
Copy link
Contributor

The lineageos patch is specific to userdebug/eng builds. The lineage os patch can be easily modified; however, for people doing manual "user" builds with lineageos4microg (me for one) should this be mentioned/flagged when making the switch?

Our docker engine only makes userdebug builds, so the LOS patch will be applied in all our automated builds. However, as mentioned above, I'm planning to keep our signature spoofing patches - which patch different files from the LOS patch - for those users of our docker build engine wish to include apps other than microG which do signature spoofing.

So, unless I've missed something and our planned approach wont' work, I don't think we will be 'making' any 'switch`, and our signature spoofing patches should continue to work for 'manual' builds

@TinfoilSubmarine
Copy link
Author

The patch has been merged.

@FintasticMan
Copy link
Contributor

For the "official" l4m builds, are you planning on including our own patches, or will you just have them available for people who want to use the container themselves? I suggest we don't apply any additional patches by default.

@petefoth
Copy link
Contributor

My current plan is not to change anything in our builds unless we need to. I believe our patches can coexist with the upstream patches.

If that proves to be wrong, then I'll think again

@FintasticMan
Copy link
Contributor

I'm not sure what our patches accomplish on a build of l4m with only microG needing to spoof signatures. I'd say that given that the goal is to make the minimum number of changes to LOS for microG to work, we shouldn't be adding these extra patches by default.

@petefoth
Copy link
Contributor

petefoth commented Feb 25, 2024

I don't disagree with your point that we should stay as close as possible to upstream as we can. However, I don't plan to make any changes in this area in a hurry - and, in particular, not before our next build run starts in four days time - for the following reasons:

  1. The March build run already involves a major, potentially 'breaking' change: making 21.0 builds for ~130 devices that have been 'promoted' from 20.0 since February's build run.
  2. That change involves changes in the area of signature spoofing - see Implement changes needed for lineage-21.0 #566
  3. The changes made for Implement changes needed for lineage-21.0 #566 have received a limited amount of testing, which has gone OK. I am relatively confident that they wont 'break' signature spoofing, but I won't be completely happy until builds involving our new patch have been in use for a while (at least a month?) with no problems reported related to signature spoofing, or to the functions provided by GmsCore which depend on it.
  4. I can see from the LOS Gerrit that their changes have been code reviewed. I can't see any evidence that the changes have been tested, and specifically tested by making a build which includes microG, and checking that signature spoofing works in that build. I'm not suggesting that such testing has not been done (although I wouldn't necessarily expect LOS to do such testing, particularly given their historical animosity towards microG and signature spoofing). But if it has been tested, I don't see the evidence.
  5. I am not going to rely on untested code to provide functionality which is core to our builds.
  6. I don't have the time or resources to do this testing myself: definitely not before the March build run, and possibly not for a while after that.
    • I need to make some new builds which include the upstream changes alongside our patches and ensure that signature spoofing doesstill work - that's an untested assumption at the moment. (The patch was only merged a few hours ago, so it is not present in the February build run).
    • If that it not the case, then the spoofing functionality will need fixing. The fix needed may involve removing our patches and relying on the upstream changes, but that will only happen as a 'last resort'.
    • There are a number of other issues that need fixing and testing before the April build run (see Put in place a process for handling 'promoted' (and 'relegated') devices #557, and Low disk space on download server (again) #505).
  7. If anyone else does have the time and inclination to run some testing (e.g. by making a los4microG build without using our patches, and using it extensively - with as much use as possible of microG features - for a few weeks), that would be very helpful, and I will be very happy to rely on their results.
  8. Until such testing has been done, and I am confident that the upstream changes do work, and that our changes are no longer necessary, we will be making our 'official' builds using both our patches and the upstream changes.

To summarise

  • I do want to move to a point where we no longer need to maintain our signature spoofing patches,
  • We are definitely not (in my opinion) in a position to do that now.
  • It will probably be a couple of months at least before we are in that position and can safely start making put builds without the patches.

@FintasticMan
Copy link
Contributor

Thank you for the explanation! You make very good points. I agree that we shouldn't change the set-up straight away. I do think that once the LOS 21 transition has finished and shown to work, we should definitely consider testing that it works without additional patches, and then not applying them.

@petefoth
Copy link
Contributor

I do think that once the LOS 21 transition has finished and shown to work, we should definitely consider testing that it works without additional patches, and then not applying them.

I agree.

The March builds are going to include the LOS changes andour patches, but unfortunately there is no time to test that the LOS changes can coexist alongside our patches: I still need to implement #557 to handle the large number of devices that will be promoted from 20.0 to 21.0. So we will be shipping untested builds, and hoping that they work. (If they don't we have to choose whether to move forwards using only our patches or only the upstream changes. Let's hope that doesn't happen!)

Before we move away from our patches in our monthly build runs, I plan the following stages of testing

  • Make builds for a small number of devices including only the LOS changes ***without ***our patches. Ideally at least one build per supported branch (i.e. 18.1, 20.0 & 21.0). These builds will not be made generally available on the download server - I will make them available, probably via sourceforge, for anyone who wants to test
  • Ask here and in the XDA forum thread for volunteers to use these builds on their 'daily driver' devices, and to report back on any problems.
  • When we are happy that running with only the LOS changes does not cause any problems, then we can stop applying our patches in the monthly build runs. If we get enough volunteers, enough testing time, and no (or not many) reported problems, then it may be possible to do that for the April build run. If not, we may have to wait a bit longer

In the longer term, if the LOS changes do work, then there will be no need for us to create our own patches when Android 14 Lineage 22 comes along :)

@TinfoilSubmarine
Copy link
Author

FWIW, I've made a build (for redfin) with none of the patches applied and it is working so far. The only confusing thing was microg/GmsCore#2207.

@petefoth
Copy link
Contributor

FWIW, I've made a build (for redfin) with none of the patches applied and it is working so far. The only confusing thing was microg/GmsCore#2207.

Thank you. I've created #576 to track the testing and record results. Please can you update the table in this post and add the branch you built? Or comment here and I'll update the table.

Could your build be made available for other redfin users to test?

Thanks again

@petefoth
Copy link
Contributor

Interesting to note the following from the IodéOS Beta Testers telegram

One remark: a signature spoofing method for microG has been merged in LineageOS. We dropped our ow patches in favor the now lineage official way. It seems to work well and should be seamless for users.

Maybe we can risk making the March builds using only the LOS changes. I will do dome more diggening in that telegram channel

@vanMacG
Copy link

vanMacG commented Feb 27, 2024

I don't disagree with your point that we should stay as close as possible to upstream as we can. However, I don't plan to make any changes in this area in a hurry - and, in particular, not before our next build run starts in four days time - for the following reasons:

It isn't directly related to signature spoofing, but there is also a bigger change coming on the microG side in the near future. We still build with v0.2.27. There changed a lot in recent versions, that's why they are still marked beta. As you mentioned in #576 i.e. FakeStore is integrated in GmsCore then (and probably don't need a spoofing anymore). Also the location backends from here are no longer needed.
I think this will also require proper testing.

@TinfoilSubmarine
Copy link
Author

FWIW, I've made a build (for redfin) with none of the patches applied and it is working so far. The only confusing thing was microg/GmsCore#2207.

Thank you. I've created #576 to track the testing and record results. Please can you update the table in this post and add the branch you built? Or comment here and I'll update the table.

Could your build be made available for other redfin users to test?

Thanks again

Branch is 21.0. I can upload my build and migration script. However, I built without android_vendor_partner_gms to test how everything works when user-installed rather than in the system, so the build could break some user's setup. That is actually what caused microg/GmsCore#2207, as when I install microg into system (using a Magisk module) the "problem" goes away.

@petefoth
Copy link
Contributor

Branch is 21.0.

Thanks

I can upload my build and migration script

My understanding (from reading the LineageOS Wik, and from my own testing attempts on different devices is that the upgrade has to be flashed manually. Does your migration script allow the upgrade to be applied by the Updater app? Or is it a script that automates the installation steps described in the Wiki? Or something else? Whatever, I'd be interested to see it.

I built without android_vendor_partner_gms to test how everything works when user-installed rather than in the system, so the build could break some user's setup.

OK, then probably not so useful for other users :)

@petefoth
Copy link
Contributor

t isn't directly related to signature spoofing, but there is also a bigger change coming on the microG side in the near future. We still build with v0.2.27. ...

I think this will also require proper testing.

I'm less worried about this.Microg v.3.0 has already been extensivley tested, bith by the microG project, and in our builds where users have updated microG using F-Droid update.

When microG do mark v.3 as stable, I'll be happy to include it without much testing by us: we don't have the resources to do much testing ourselves, and we rely on our upstreams to do the testing, and trust them not to deliver problems :)

My concern with the LOS signature spoofing changes is that I'm not aware of upstream having done much testing. They may have done - they are very good software engineers - but I don't have any visibility of that testing, byeond the Gerrit records of code reviews.

All that said, the results of the IodéOS beta testing of their 5.0 (Android 14 / LOS 21) builds - which use the LOS changes instead of Iodé's own spoofing patches - is looking very positive. Everything seems to be working, and no reported problems with microG. So I am probably going to risk not applying our patches in the March build run. I'll try and do some tests of my own, and I don't have to make a decision until around 23:50 on Thursday :)

@TinfoilSubmarine
Copy link
Author

TinfoilSubmarine commented Feb 28, 2024

Branch is 21.0.

Thanks

I can upload my build and migration script

My understanding (from reading the LineageOS Wik, and from my own testing attempts on different devices is that the upgrade has to be flashed manually. Does your migration script allow the upgrade to be applied by the Updater app? Or is it a script that automates the installation steps described in the Wiki? Or something else? Whatever, I'd be interested to see it.

I just took the microg key signatures from https://download.lineage.microg.org/extra/lineageos-for-microg-keys-migration.zip, exported mine using lineage/scripts/key-migration/export-keys.sh, and then used lineage/scripts/key-migration/migration.sh with the updated keys. You might want to update that zip since it looks like the upstream script has changed to support newer versions of Android.

I built without android_vendor_partner_gms to test how everything works when user-installed rather than in the system, so the build could break some user's setup.

OK, then probably not so useful for other users :)

Let me know if you would still like me to make it available--otherwise I will plan on not 👍

@olokelo
Copy link

olokelo commented Feb 29, 2024

Hi all, thanks for your work and testing.

I was planning to start using LineageOS with MicroG on my primary device just after LineageOS 21 got released.

However right now I'm more than confused, I've never used LineageOS before. Seeing the amount of changes hapenning right now I'm not sure if maybe I should wait another couple months. Do you think your March build will be stable enough? Could there be potential issues with system upgrade if you decide to drop your sig spoofing patches in the future?

Thank you

@petefoth
Copy link
Contributor

I was planning to start using LineageOS with MicroG on my primary device just after LineageOS 21 got released.

However right now I'm more than confused, I've never used LineageOS before. Seeing the amount of changes hapenning right now I'm not sure if maybe I should wait another couple months. Do you think your March build will be stable enough? Could there be potential issues with system upgrade if you decide to drop your sig spoofing patches in the future?

The big change is the move to lineage-21. That's pretty new for all devices, but from what I've read it hasn't caused a lot of problems. I usually delay upgrading to a new Android version for a month or two af5er it is first released, and I keep my eye open for problems with my device. What device do you have? It might be worth finding the XDA Forum thread, for Lineage OS on your device if there is one. See what people there are saying.

The other change, specific to our los4microg builds, is dropping our signature spoofing patches and using the upsream changes instead. I was reluctant to do this initially, but everything I have read and experienced in the last week indicates that it won't cause any problems. So our March build run - which starts at midnight tonight UTC - will include the change. If you keep any eye open here, and in our XDA Forum thread, you should get an idea of what problems - if any - people are encountering, and whether it's OK to upgrade now, or better to wait.

@olokelo
Copy link

olokelo commented Feb 29, 2024

Thank you for explaining the changes in detail. It's good to know lineageos4microg will be shipping "official" sigspoofing patches from LineageOS.

I have Oneplus 7T (hotdogb) and I will be happy to report any problems if I encounter them later.

@petefoth
Copy link
Contributor

I have Oneplus 7T (hotdogb) and I will be happy to report any problems if I encounter them later.

In that case keep an eye on [this XDA forum thread(https://xdaforums.com/t/rom-official-hotdogb-14-lineageos-21.4657089/] (for the official LineageOS 21.0 ROM

@petefoth
Copy link
Contributor

I have just found out (from the Iodé Beta Testers Telegram channel, that in pstream LineageOS, signature spoofing in los, is disabled for user builds. Not a problem for our builds as we make userdebug builds, but others may need to know

@petefoth
Copy link
Contributor

Signature spoofing using the upstream LOS changes seems to be working fine. Closing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants