Trying to revive 'ubtd' (Bluetooth file transfer)

gpatel-fr

Err, I wanted to wrote 'restricted applications can access Internet'. But it don't matter much.

Anyway, I tried to regenerate the click without the unconfined template. Now, the confined app can send files to the Android phone without problem at all. It's in the other direction that I get an authorization error:

févr. 19 10:28:19 ubuntu-phablet obexd[3879]: Agent replied with an error: org.freedesktop.DBus.Error.AccessDenied, An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.0" (uid=32011 pid=3879 comm="/usr/libexec/bluetooth/obexd -P ftp,irmc,mas,pcsui" label="unconfined") interface="org.bluez.obex.Agent1" member="AuthorizePush" error name="(unset)" requested_reply="0" destination=":1.116" (uid=32011 pid=7190 comm="ratatoskr" label="ratatoskr.petroniusniger_ratatoskr_0.1.0 (enforce)")

Now I don't think anymore that it's a matter of setting the system to grant the authorization. You see, in the other direction on the Android phone I get a prompt to authorize the transfer. The UT phone can't simply push files to the Android phone without any user interaction.
And I think that this should be the fix: that somehow the UT user (phablet) get a prompt to grant the other system the (temporary) right to write the file to the UT destination.
Granted, I don't have currently the slightest idea on how to proceed from that

gpatel-fr

The MR got merged by the way. Now it's in 24.04-2, not in the stable version.

I could ask in the appropriate thread to sneak this change in the 24.04-1.2RC3 if there is any (don't seem likely). Or maybe you could ask yourself since it's your app ?

PhAndersson

@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):

@PhAndersson

Anyway, I tried to regenerate the click without the unconfined template. Now, the confined app can send files to the Android phone without problem at all. It's in the other direction that I get an authorization error:

Yes, I'm aware of this -- I already reported this higher up in this thread. The SharePlugin works fine with a confined AppArmor profile. It's only the main app that needs wider rights to interact with D-Bus / OBEX.

Now I don't think anymore that it's a matter of setting the system to grant the authorization. You see, in the other direction on the Android phone I get a prompt to authorize the transfer. The UT phone can't simply push files to the Android phone without any user interaction.
And I think that this should be the fix: that somehow the UT user (phablet) get a prompt to grant the other system the (temporary) right to write the file to the UT destination.

Having a prompt for the user to accept the incoming transfer is indeed needed (and already tracked through issue #6), but I don't see this as related to the fact that a confined AA profile prevents the app from issuing the "AuthorizePush" message.

This clearly needs further investigation.

PhAndersson

I've hit a snag. I'm supposed to contact the review team on Telegram to try and get my app approved for publication on the OpenStore, but it seems I can't create a Telegram account through the UT Teleports app -- it says the official Android or iOS app is required to do this, which I don't have access to.

I'll try to contact 'bhdouglass' via the forum instead.

arubislander

@PhAndersson said in Trying to revive 'ubtd' (Bluetooth file transfer):

it says the official Android or iOS app is required to do this, which I don't have access to

I have heard Telegram works on Waydroid, fwiw.

PhAndersson

@arubislander said in Trying to revive 'ubtd' (Bluetooth file transfer):

@PhAndersson said in Trying to revive 'ubtd' (Bluetooth file transfer):

it says the official Android or iOS app is required to do this, which I don't have access to

I have heard Telegram works on Waydroid, fwiw.

Thanks for the tip -- I'll give it a look.

gpatel-fr

@PhAndersson said in Trying to revive 'ubtd' (Bluetooth file transfer):

if the obexd issue can be solved at platform level, the app could be ported to 24.04 with minimum effort.

as they say in open source, 'unfortunately' the MR was backported to the 24.04-1.x too late to be included in the 24.04-1.2 version . That means that your app will not work at all in this version unless some system fiddling is done by the user.

paulcarroty

@PhAndersson there's active OpenStore matrix room.

PhAndersson

@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):

as they say in open source, 'unfortunately' the MR was backported to the 24.04-1.x too late to be included in the 24.04-1.2 version . That means that your app will not work at all in this version unless some system fiddling is done by the user.

So this means waiting for 24.04-2/stable, I guess...

gpatel-fr

@PhAndersson said in Trying to revive 'ubtd' (Bluetooth file transfer):

waiting for 24.04-2/stable,

or 24.04-1.3, whatever comes first. I'd bet on 24.04-1.3 but who knows?

as a status update, my available bandwidth has been dedicated to try to find a solution for the dbus rights problem (I have again flipflopped in my opinion about this matter, I have seen in the app code where it was supposed to prompt the user and instead it is always answering 'yes').
However Apparmor is not the easiest thing in the world to configure, so far I had no success.

about the confined apps being forbidden, there are in fact quite a few unconfined apps in the store, most of the ones I know of are managed by 'core' developers, but not all - as far as I know PureMaps is not maintained by a core Ubuntu touch developer; so it's mostly a matter of trust.

PhAndersson

@paulcarroty said in Trying to revive 'ubtd' (Bluetooth file transfer):

@PhAndersson there's active OpenStore matrix room.

Many thanks -- I just joined it.

PhAndersson

Status update:

'ratatoskr' source code has just been reviewed by @bhdouglass (OpenStore team), and two issues have been identified that should be resolved before allowing publication of the .click packages:

https://github.com/petroniusniger/ratatoskr/issues/12 (new one)
https://github.com/petroniusniger/ratatoskr/issues/6 (known issue)

I'll work on resolving those 2 issues and release a v0.1.1 of the code before re-submitting it for publication.

PhAndersson

Final status update: the app has passed the code review and v0.1.1 is now available on the OpenStore.

You will find it under the name "Bluetooth file transfer", in the "Utilities" category.

If you install it, may I suggest that you check the README here: https://github.com/petroniusniger/ratatoskr/tree/main for a brief description of how to use it most effectively?

Also, should you discover any bug, please report them here: https://github.com/petroniusniger/ratatoskr/issues

domubpkm

@PhAndersson Not tested yet. But thank you for your work and perseverance.

domubpkm

@PhAndersson Should the app be shown in UT TT apps ? I don't see anything on my Volla 22. What should be the names of the cache config data directories ?

PhAndersson

@domubpkm said:

@PhAndersson Should the app be shown in UT TT apps ? I don't see anything on my Volla 22.

I'm sorry, I guess I'm a bit slow tonight, but I'm not clear on what 'TT' means in this context. Can you clarify?

What should be the names of the cache config data directories ?

The app cache is in ~/.cache/ratatoskr.petroniusniger/. This is where incoming files are kept -- but there is no config data there (the app doesn't store any configuration data at this stage).

domubpkm

@PhAndersson UT Tweak Tool https://open-store.io/app/ut-tweak-tool.sverzegnassi

PhAndersson

Sure, Tweak Tool, of course -- sorry.

I just checked on my phone and it shows there, yes. Just look under the name 'Ratatoskr' (that's the actual name I gave the app -- "Bluetooth file transfer" is only a description).

It's the first UT app I built, so I'm not familiar yet with all the intricacies of the dev. workflow.

In any case, it seems there was a mixup, as the packages that were pushed on the server are v0.1.0, not v0.1.1. The "file sending" functionality may not be functional in that version (the receiving one should be).

I'll try to get this fixed tomorrow.