Rhythmbox & daap with itunes 7, 8, 9, 10 doesn't work correctly

This is no avahi bug but a bug in rhythmbox and banshee
Avahi only helps these applications to find the shared music but doesn't do anything with DAAP.

Which iTunes version are you using?

It was on my brother's computer, I think he did the latest update, so it should be Itunes 7.
I'll check tomorrow to be sure.

Ok, this issue is known with itunes 7... someone was working on it AFAIK

I checked, it was indeed Itunes v7

Should be fixed with banshee 0.11.1-0ubuntu1

Upstream bug about that: http://bugzilla.gnome.org/show_bug.cgi?id=356627

I'm currently using banshee-daap 0.11.5 and it gives me a nice message that iTunes7 is not supported. I'de like to say this is not a "fix" for the problem as I still can not access the shares. The daap protocol needs to be updated so this works.

I went on IRC the the banshee channel and basically got "This will never work" and "tell your friends the badness of DRM and have them switch." So should I tell them to switch and be in the same boat I'm it, a broken non-functional sinking (more people are switching to iTunes7) boat?

I know DRM is bad, you either go with it (and put the time in to reverse engineer the protocol) or make no progress forward (who would switch to a system that have less functionality.)

So as a user friendly desktop Ubuntu should keep this bug open and put pressure up-stream to truly FIX the problem (not our fault, but its our problem!)

FYI: with banshee 0.12.1 (feisty fawn) daap + iTunes 7.1 work for me.

Bastian, thats impossible. You are probably confused as to what the problem is. iTunes 7 blocks anyone from accessing its music share. However, it is able to to access the music shares of others.

This bug is present for me in Gutsy and Rhythmbox 0.11.2. Rhythmbox can connect to an iTunes 7 share, and iTunes will report that someone is connected, but RB will be unable to communicate at all from the iTunes share, and the track listing for the share will remain completely blank.

This must be an upstream bug...

Note that you can install Tangerine on your OS X machine:

http://www.snorp.net/log/tangerine

to share your iTunes library using the old version of DAAP, so that Banshee/Rhythmbox/etc can still see it.

I have the same issue, but through browsing various forums, it seems that this change is caused by the latest iTunes update (iTunes 7). All iTunes clients can see my shared music (done through rhythmbox). I can see iTunes7's shares, but cannot access the libraries themselves.

I can confirm this behaviour with the latest rhythmbox on gutsy.

Can we tag this as "won't fix"(at least in a while) because Banshee already shows a message telling you the problem, that is not our fault(Apple's).

BTW, this can be sound very weird, but, have we look into a some type of collaboration with Apple? I mean, I know that they are probably one of the most evil companies in the world, but maybe they are open to help.

Its interesting how this report keeps popping up every now and again. When I
filed it I hopped it would be fixed but it has not. I understand that apple
"broke" the protocol. and I use quotes because it is their protocol so they
really can break it, can they? I know, they made it more difficult to work
with, maybe impossible. But I've seen the OSS world do some rather
impressive things, I just find it hard to believe that after this long
someone out there couldn't get this to work.

I don't have the skills or the time to acquire them so this is not a
complaint on my part, just a reply to the last message I got. I think that
if this bug will not be fixed or actively worked on it should be marked as
"won't fix." As disappointing as that is to me, and I'm sure many many other
people out there.

On Sat, Mar 8, 2008 at 4:18 AM, Igor Guerrero <email address hidden> wrote:

> Can we tag this as "won't fix"(at least in a while) because Banshee
> already shows a message telling you the problem, that is not our
> fault(Apple's).
>
> BTW, this can be sound very weird, but, have we look into a some type of
> collaboration with Apple? I mean, I know that they are probably one of
> the most evil companies in the world, but maybe they are open to help.
>
> --
> daap with itunes 7 doesn't work correctly
> https://bugs.launchpad.net/bugs/62842
> You received this bug notification because you are a direct subscriber
> of the bug.
>

exageration is not really useful there, there is no indication that many many users are concerned about that, launchpad got 3 bugs about it, upstream got no duplicate. It's also likely that displaying an error with not be enough for most users who want to use itunes, still the blame is on apple who decised to make changes preventing a such use and not on ubuntu or the opensource community

the bug will not be closed as wontfix but getting that working is likely not trivial which explain it's not done yet

Bad story.

I should work. Bad Apple.

It is unlikely that anyone will ever find a way to read Itunes DAAP shares. The reason is that they now use public key encryption to ensure that the client connecting really is another ITunes v.7.0 client. To connect you would basically need to break their encryption which would be pretty difficult, if not impossible.

http://www.google.com/gwt/n?u=http://www.webpages.ttu.edu/mroth/tunes/login.htm

Based on Lamah's info, it sounds like there is no way we can fix it. Still, I tried out rhythmbox on Intrepid Alpha 6 and it fails to connect all the same without displaying any error message (that Apple makes their shares incompatible with 3rd parties.) I believe it would be very helpful for the average user to see such an error message.

I don't know if the guys from saveourtunes.com have this problem, as they did a release about 2 days before lamah's comment? I have no idea what the status is on that project personnally, but I'd tend to think it could be used for rhythmbox?

The difference between this issue and a working build of ourtunes, is that ourtunes tunnels durectly through itunes, solving the cross-client enryption issue. In order for this to work, rhytmbox would need to spoof itself as an itunes client, or route itself through a tunnel that did such.

>> It is unlikely that anyone will ever find a way to read Itunes DAAP shares. The reason is that they now use public key
>> encryption to ensure that the client connecting really is another ITunes v.7.0 client. To connect you would basically need
>> to break their encryption which would be pretty difficult, if not impossible.

>> http://www.google.com/gwt/n?u=http://www.webpages.ttu.edu/mroth/tunes/login.htm

I understand that public key encryption would be impossible to break by "reverse engineering techniques",
but (correct me if I'm wrong here) don't such encryption systems use a private key too?

And if so, can an "original" private key (used by and Apple iTunes 7 client) be somehow obtained?
Perhaps by listening to conversations between two iTunes players?

And if we get that kind of key, can rythmbox/banshee use it to connect to iTunes 7+ servers?
If any portion of what I've said is an impossibility, please do tell me.

Not much use without the private key but I'm fairly certain that this is what the server uses for encrypting the data:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            33:33:af:06:08:23:af:00:01:af:00:00:09
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=Apple Computer, Inc., OU=Apple Computer Certificate Authority, CN=Apple FairPlay Certificate Authority
        Validity
            Not Before: Aug 23 18:22:34 2006 GMT
            Not After : Aug 22 18:22:34 2011 GMT
        Subject: C=US, O=Apple Computer, Inc., OU=Apple Computer FairPlay, CN=FP.3333AF060823AF0001AF000009
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:e5:92:25:bb:c6:83:08:b6:74:5c:78:3b:c8:b6:
                    a6:69:25:dd:85:48:26:81:04:75:e1:a2:64:7c:5b:
                    6c:05:f3:ed:e8:68:7d:12:65:e0:a0:66:b7:59:52:
                    79:ef:4b:e4:69:ad:e8:d0:46:c1:a0:07:bf:ea:aa:
                    35:a4:a7:7b:25:c6:9f:70:f9:95:9a:67:44:1a:38:
                    54:be:2c:0e:ac:6c:72:2d:db:9e:29:1c:7f:23:a6:
                    bd:3b:23:33:e4:91:9e:ae:d1:68:0c:9e:c2:49:d5:
                    7f:b2:30:22:c6:99:24:c6:6d:cb:73:68:a7:34:4b:
                    b9:a1:91:5e:0d:39:23:00:a9
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                70:59:25:54:24:25:79:62:4E:AE:A6:E1:6F:98:1B:2E:A7:6D:33:78
            X509v3 Authority Key Identifier:
                keyid:D6:9B:6F:87:B8:02:01:D2:A6:60:D9:00:72:4D:28:98:4C:CE:14:20

    Signature Algorithm: sha1WithRSAEncryption
        24:f5:61:0a:5d:d9:1a:24:7b:34:92:11:1d:1c:d0:20:a7:20:
        05:74:e5:de:66:ee:57:cd:5a:6b:c7:1c:02:75:37:48:b1:d2:
        e2:a7:cb:26:6b:d5:84:f6:17:6c:7e:6d:1e:0b:12:0f:85:04:
        50:54:e3:44:e9:6a:d3:a2:14:48:d2:70:91:0b:0d:21:7b:b7:
        eb:6b:ae:65:0a:e7:09:36:44:10:08:29:7d:43:de:e7:3b:86:
        7f:f1:07:35:57:e0:35:34:e6:33:6c:42:b4:db:03:f7:e4:64:
        5b:20:f5:05:01:7b:a0:7b:2d:a1:88:19:62:e4:d2:55:03:79:
        35:69
-----BEGIN CERTIFICATE-----
MIIC4zCCAkygAwIBAgINMzOvBggjrwABrwAACTANBgkqhkiG9w0BAQUFADCBijEL
MAkGA1UEBhMCVVMxHTAbBgNVBAoTFEFwcGxlIENvbXB1dGVyLCBJbmMuMS0wKwYD
VQQLEyRBcHBsZSBDb21wdXRlciBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxLTArBgNV
BAMTJEFwcGxlIEZhaXJQbGF5IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wNjA4
MjMxODIyMzRaFw0xMTA4MjIxODIyMzRaMHYxCzAJBgNVBAYTAlVTMR0wGwYDVQQK
ExRBcHBsZSBDb21wdXRlciwgSW5jLjEgMB4GA1UECxMXQXBwbGUgQ29tcHV0ZXIg
RmFpclBsYXkxJjAkBgNVBAMTHUZQLjMzMzNBRjA2MDgyM0FGMDAwMUFGMDAwMDA5
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlkiW7xoMItnRceDvItqZpJd2F
SCaBBHXhomR8W2wF8+3oaH0SZeCgZrdZUnnvS+RprejQRsGgB7/qqjWkp3slxp9w
+ZWaZ0QaOFS+LA6sbHIt254pHH8jpr07IzPkkZ6u0WgMnsJJ1X+yMCLGmSTGbctz
aKc0S7mhkV4NOSMAqQIDAQABo2AwXjAOBgNVHQ8BAf8EBAMCA7gwDAYDVR0TAQH/
BAIwADAdBgNVHQ4EFgQUcFklVCQleWJOrqbhb5gbLqdtM3gwHwYDVR0jBBgwFoAU
1...

Rhythmbox shouldn't display shares it doesn't support. Or it should display them clearly marked as broken and instead of "retrieving songs" it should say "Unable to retrieve songs from iTunes 7" + a clickable link to some place explaining workarounds.

I changed the subject line to make it more descriptive. Here is what I changed, and my reasons:

   * The subject line said "DAAP" but it seems that the bug description and most of the comments actually say "Rhythmbox" or "Banshee".
   * Also, this problem is present in iTunes version 10. I believe this affects iTunes versions 7 through 10 (e.g. all modern versions).

I agree with @Artem Baguinski. If the Ubuntu program does not support this newer protocol, then the program should say something like "iTunes 7 and above are not supported". I believe that the Apple iTunes client will advertise it's version, so hopefully this would be easy to detect.

Currently, Rhythmbox says it's connecting to the remote iTunes share, and will sit there forever. This is misleading and bad behavior.

Changing it to list a specific app is unnecessary. They all use the same
library to do DAAP. It's the library, not the applications, which would need
to be changed.

Also, to fix this bug, modern cryptography would need to be totally broken. Or
Apple's key would need to be stolen. One of the two. In the latter case,
they'd issue a software update to change the key.

There is another fix to this issue other then illegally cracking a private key.

As @Artem Baguinski suggested, if this software is unable to connect to shares from iTunes 7 and above, then it should say something like "Unable to retrieve songs from iTunes 7".

Really, this feature is useless. It sounds like it hasn't worked since iTunes 7 was released many years ago, and only works with deprecated software like iTunes 6 and earlier. This feature doesn't work with modern software and should be removed, to prevent confusion.

It is useful to connect to other daap-applications that aren't using this annoying private key.