Description of problem: When testing out https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2, I can no longer pair with my iOS device. Version-Release number of selected component (if applicable): libplist-2.2.0-6.fc36.src.rpm How reproducible: Always Steps to Reproduce: 1. update-crypto-policies --set TEST-FEDORA39 2. Reboot 3. Trust computer on device 4. idevicepair pair 5. idevicepair validate Actual results: Pairing should fail, libplist will complain about not being able to find the device's XML file in /var/lib/lockdown. Expected results: Pairing succeeds. libplist reports no error. Additional info:
It's obviously not libplist's fault, it doesn't do any crypto. Even then, I'm sorry but I don't see how I can do anything about it. The page listed doesn't help me find solutions to this problem. Am I supposed to ask Apple to change the algorithms they use? This wouldn't work for older phones or tablets...
(and that's me reassigning to the correct package) https://github.com/libimobiledevice/libimobiledevice/search?q=sha1
Hi, I did initially put the wrong component, but wasn't sure since libimobiledevice, et al. kind of work together, but you are correct that libimobiledevice is the one that actually does crypto. > Even then, I'm sorry but I don't see how I can do anything about it. The page listed doesn't help me find solutions to this problem. Am I supposed to ask Apple to change the algorithms they use? This wouldn't work for older phones or tablets... I'm simply reporting the issue per the test day instructions. The actual discussion on the proposal can be found within the issue tracker/mailing list linked within. I have no further context as I'm only a tester. > Am I supposed to ask Apple to change the algorithms they use? sha1 is deprecated in iOS 13 and practically speaking older phones are not really usable due to planned obsolescence. So they will stop using sha1 eventually anyway.
(In reply to remyabel from comment #3) > > Am I supposed to ask Apple to change the algorithms they use? > > sha1 is deprecated in iOS 13 and practically speaking older phones are not > really usable due to planned obsolescence. So they will stop using sha1 > eventually anyway. There are plenty of usable iPhones, iPads and iPod Touches that can't be updated to iOS 13 that we still need to support. Anyway, this isn't actionable from my side, so this will stay open until it's fixed, or something.
Note that the changes in crypto-policy do not disallow the use of SHA-1 in general, just using SHA-1 in signatures and signature verification. I'm not sure where exactly libmobiledevice uses SHA-1 in signatures, but at least one of the places seems to be https://github.com/libimobiledevice/libimobiledevice/blob/8bfa46bdf404af39d32b7cba8f0102b46a6a43e0/common/userpref.c#L422 where X.509 certificates are generated with SHA-1 signatures. Is the use of SHA-1 in these X.509 certificates mandatory for interoperability with older Apple devices, or could they potentially accept SHA-256 instead? Additionally, once the changes proposed in StrongCryptoSettings3 are implemented, https://github.com/libimobiledevice/libimobiledevice/blob/32d531a955b9a099e3418e84ef31f4b041974a4d/src/idevice.c#L1147 should probably be adjusted to set the minimum TLS version to 1.0 and re-enable SHA-1 and SHA1-MD5 again. We're working on a way to do this in OpenSSL with upstream (see https://github.com/openssl/openssl/issues/17662 and https://github.com/openssl/openssl/pull/19084), but that's work in progress.
So, the foremost question is whether `X509_sign(root_cert, root_pkey, EVP_sha1());` can be turned into an `X509_sign(cert, pkey, EVP_sha256())` and still interoperate, right? Could somebody with an access to a pre-iOS 13 devices try that?
With all due respect, when a non RedHat employee files a bug report following precise instructions, responding with "I don't see what you expect me to do about it" is rude. This isn't the first time I've received a response like this in a bug report and it boggles my mind. You are free to say "This is not actionable on my side" then close it as "WONTFIX" or similar. I'll even accept "file a bug report with libimobiledevice". Actually, that seems like the better approach since as you said, this isn't fixable on the packaging side. Regardless, I don't work at RedHat so I don't know what your SOPs are, but it seems like we are going to ask users to file bug reports, there should be some intercompany communication so that colleagues are not receiving random bug reports. I'm closing this in favor of notifying the libimobiledevice project instead.
I'm sorry for this getting emotional, even though I'm not sure how we got there. The intent of the test day was to identify the "dark corners" of Fedora that are going to be affected by the proposed crypto-policies tightening, a task that remyabel has excelled at (I, for one, wouldn't ever suspect libimobiledevice to be affected). So, big thanks to remyabel for discovering the workflow and filing the bug, which was meant to kickstart the followup investigation of what exactly broke the user experience. Re. Red Hat vs non-Red Hat, I'm not sure I follow the separation. This is a Fedora activity, devised to soften the blow for Fedora users and developers when Fedora (one day or another) stops trusting SHA-1 signatures. We've already shipped RHEL-9 that doesn't, but RHEL-9 doesn't even include libimobiledevice, so the only thing Red Hat about this bug should the fact that some of our emails end in redhat.com. Sadly, that doesn't grant us any hivemind powers =( Reopening the bug because it's a valid workflow for Fedora users, one that conflicts with distrusting SHA-1 signatures. Unfortunately I don't own a single iOS device to test against, so my ability to contribute is rather limited. Maybe it's just an s/EVP_sha1/EVP_sha256/ away from being solved. Maybe we need to have an exception for libimobiledevice. Maybe this bug will be the last drop to postpone the change in Fedora? I don't know. Would anybody kindly help with figuring it out?
Upstream bug: https://github.com/libimobiledevice/libimobiledevice/issues/1355
That was my bad and a completely inappropriate reaction on my part. I lashed out because I've had frustrations when contributing to the Fedora project and some of the responses I've gotten. Everything I said was as you pointed out emotionally charged and should not have been said. Regardless, I took a look at the issue and tagged the maintainer.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.