looking for equipment donations

[Dirk Hohndel via subsurface]

One of the many things that I end up doing is testing various things across 
various devices.
And I have noticed that while I have more than a dozen dive computers, those 
skew towards modern, color, BLE devices.
With the recent work on USB-serial for Android I realize that I am missing 
quite a few of the still very common ones out there.
- old style Suunto like the Gekko, Zoop, Vyper, Vyper Air
- anything Oceanic (and all the brands that share the underlying platform)
- anything Uwatec
- anything Cressi or Zeagle or... with a Prolific download cable
- a Mares with a SiliconLabs cable (I have an Icon HD which uses a different 
cable / interface)

If one of you happens to have something on that list that they no longer need 
and use, I would appreciate a donation. Please reach out.

Thanks

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface Mobile: Adding mares USB (cp210x) support; how to proceed

[Dirk Hohndel via subsurface]

> On Mar 7, 2020, at 8:46 AM, Stephen Goodall 
>  wrote:
> 
> Hi Christof,
> The Cressi worked 😁
> The Suunto said there was an error (attached) - I've not used this on my 
> phone before as it's my partner's computer so it's possible that I'm doing 
> something wrong with it! It did read it and show the device ID so it must be 
> talking to it.

Can you please try again with the Suunto, and after you get the error, instead 
of taking a screen shot, please submit a support request from the app - this 
will copy the logs into your email program. You can send that email to the 
support address that auto-populates, or you can change the 'To' address and 
send it to the mailing list... but this will give us more detailed logs that 
might tell us what's going wrong.


/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface Mobile: Adding mares USB (cp210x) support; how to proceed

[Christof Arnosti via subsurface]

Hi Stephen,

On 07.03.20 17:46, Stephen Goodall wrote:
> Hi Christof,
> The Cressi worked 😁
Good to hear!
> The Suunto said there was an error (attached) - I've not used this on
> my phone before as it's my partner's computer so it's possible that
> I'm doing something wrong with it! It did read it and show the device
> ID so it must be talking to it.

Not so good to hear...

I'm sure you did it the right way, but Suunto Zoop and Suunto Zoop Novo
use different driver classes, you did select the correct one?

Sadly libdivecomputer is built with logging disabled for subsurface, so
the generic error message "Dive data import error" is the only thing I
get here, and from this I don't really have a point to start working on.
@Dirk: Since I would expect that there might be quite some errors when
trying to import with the new method, would it be possible to enable
libdivecomputer-logging for android builds? Also, would these messages
also end up in the log which is accessible from inside the application?

Best regards
Christof

>
> On both of them, the intent thing pops up and the Cressi/Suunto is pre
> selected still like it used to. I just picked the model and the usb
> serial option, then force download all dives to be sure.
>
> Cheers!
>
> On Sun, 8 Mar 2020, 3:26 am Christof Arnosti,  > wrote:
>
> Hi Stephen,
>
> I hope that it will work with most computers using usb-to-serial
> interfaces. The underlying usb-serial-for-android implementation
> supports quite some chipsets.
>
> I'd love for you to test the implementation!
>
> You can grab a CI-Built apk from
> 
> https://github.com/Subsurface-divelog/subsurface/suites/505662208/artifacts/2634973
> for testing. The source can be found at
> https://github.com/charno/subsurface/tree/android-serial-clean,
> the pull request at
> https://github.com/Subsurface-divelog/subsurface/pull/2647.
>
> Best regards
> Christof
>
> On 07.03.20 17:22, Stephen Goodall wrote:
>> Will this affect all USB computers with Android? Very exciting!!
>> I had a look but made no progress (C++ is not something I've
>> worked with so it would have been a miracle if I had made
>> progress :D )
>>
>> I've got a Cressi Leonardo and a Suunto Zoop, and an Android 9
>> phone if you want me to test those out with any changes. Let me
>> know the branch and I can build it and test it out
>>
>> Cheers!
>>
>> On Sun, 8 Mar 2020, 3:14 am Dirk Hohndel via subsurface,
>> > > wrote:
>>
>>
>>
>>> On Mar 7, 2020, at 5:27 AM, Christof Arnosti
>>> mailto:cha...@charno.ch>> wrote:
>>>
>>> Hi Dirk,
>>>
>>> I did the integration of the Icon HD VID/PID pair, so if the
>>> testing is successful I think there is nothing left for me
>>> to do before a merge.
>>>
>>
>> I will play with this in a couple of hours and most likely
>> merge your changes.
>>
>>> Someone just tested with an Mares Nemo Wide (Serial <
>>> 5), and it did also work.
>>>
>>
>> Excellent.
>>
>>> Just for clarification about the possible UI changes (now
>>> that I'm more awake again), I would envision a workflow like
>>> this:
>>> - When opening the divecomputer-screen, or pressing the
>>> refresh button ("Neu Scannen" in german), get all UsbDevices
>>> by issuing UsbManager.getDeviceList(). Use these to populate
>>> the connection ("Verbindung") list. (Only show the entries
>>> with specified driver-class when this is activated in the
>>> settings). I think there has to be done some work in the
>>> bt-discovery part so that these two mechanisms can work
>>> together.
>>>
>>
>> I'm not sure what you mean by only showing the entries with a
>> specified driver class. I thought the driver class is
>> something that you would select in that Connection drop down
>> as an alternative to the found devices.
>> My guess is that on the vast, vast majority of Android
>> devices you will only ever get one USB device. Maybe if
>> someone uses a hub for some reason (maybe to power the phone
>> while reading dives?) one might see more, but in general that
>> would surprise me.
>> So we should optimize the user experience for the common
>> case. Which means to try and identify the one USB serial
>> device that is connected.
>>>
>>> - When a device from the connection list is selected, maybe
>>> try to guess Vendor / Model by data provided in the
>>> UsbDevice-Object. There is already some code in
>>> QMLManager::showDownloadPage. I'm not sure how much there
>>> can be done since it seems that a lot of devices use the
>>> same PID/VIDs.
>>>
>>
>> Correct - I played with th

Re: Subsurface Mobile: Adding mares USB (cp210x) support; how to proceed

[Christof Arnosti via subsurface]

Hi Stephen,

I hope that it will work with most computers using usb-to-serial
interfaces. The underlying usb-serial-for-android implementation
supports quite some chipsets.

I'd love for you to test the implementation!

You can grab a CI-Built apk from
https://github.com/Subsurface-divelog/subsurface/suites/505662208/artifacts/2634973
for testing. The source can be found at
https://github.com/charno/subsurface/tree/android-serial-clean, the pull
request at https://github.com/Subsurface-divelog/subsurface/pull/2647.

Best regards
Christof

On 07.03.20 17:22, Stephen Goodall wrote:
> Will this affect all USB computers with Android? Very exciting!! I had
> a look but made no progress (C++ is not something I've worked with so
> it would have been a miracle if I had made progress :D )
>
> I've got a Cressi Leonardo and a Suunto Zoop, and an Android 9 phone
> if you want me to test those out with any changes. Let me know the
> branch and I can build it and test it out
>
> Cheers!
>
> On Sun, 8 Mar 2020, 3:14 am Dirk Hohndel via subsurface,
>  > wrote:
>
>
>
>> On Mar 7, 2020, at 5:27 AM, Christof Arnosti > > wrote:
>>
>> Hi Dirk,
>>
>> I did the integration of the Icon HD VID/PID pair, so if the
>> testing is successful I think there is nothing left for me to do
>> before a merge.
>>
>
> I will play with this in a couple of hours and most likely merge
> your changes.
>
>> Someone just tested with an Mares Nemo Wide (Serial < 5), and
>> it did also work.
>>
>
> Excellent.
>
>> Just for clarification about the possible UI changes (now that
>> I'm more awake again), I would envision a workflow like this:
>> - When opening the divecomputer-screen, or pressing the refresh
>> button ("Neu Scannen" in german), get all UsbDevices by issuing
>> UsbManager.getDeviceList(). Use these to populate the connection
>> ("Verbindung") list. (Only show the entries with specified
>> driver-class when this is activated in the settings). I think
>> there has to be done some work in the bt-discovery part so that
>> these two mechanisms can work together.
>>
>
> I'm not sure what you mean by only showing the entries with a
> specified driver class. I thought the driver class is something
> that you would select in that Connection drop down as an
> alternative to the found devices.
> My guess is that on the vast, vast majority of Android devices you
> will only ever get one USB device. Maybe if someone uses a hub for
> some reason (maybe to power the phone while reading dives?) one
> might see more, but in general that would surprise me.
> So we should optimize the user experience for the common case.
> Which means to try and identify the one USB serial device that is
> connected.
>>
>> - When a device from the connection list is selected, maybe try
>> to guess Vendor / Model by data provided in the UsbDevice-Object.
>> There is already some code in QMLManager::showDownloadPage. I'm
>> not sure how much there can be done since it seems that a lot of
>> devices use the same PID/VIDs.
>>
>
> Correct - I played with that back when working on the Intent code
> and while there are a couple you can explicitly identify, for most
> that is not possible
>
>> - When the download-button is pressed, the UsbDevice-Object of
>> the selected connection (and if selected the name of the
>> driver-class) should be passed to serial_android_usb_open. From
>> there on I can do the work.
>>
>
> So again, you are suggesting to have a second (or actually,
> fourth?) drop down with a driver class?
>
>> There would probably also have to be done some changes when
>> receiving the USB_DEVICE_ATTACHED intent so that the correct
>> entry of the list is preselected.
>>
>
> I believe so.
>
> /D
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> 
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: mailing list changes

[Dirk Hohndel via subsurface]

That's because any sane mailing list by default does NOT send responses back to 
the mailing list.
Otherwise you get the all time favorite "personal message sent to the list" 
effect. I am sadly on a couple of mailing lists that are mis-configured like 
that, and it is very annoying.
This was my biggest fear when switching, but clearly the mailman authors had 
that already handled.

/D

> On Mar 7, 2020, at 5:39 AM, tormento via subsurface 
>  wrote:
> 
> When I reply from Gmail I always have to change the address or the mail will 
> be apparently sent to the person, not to the mailing list.

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface Mobile: Adding mares USB (cp210x) support; how to proceed

[Christof Arnosti via subsurface]

On 07.03.20 17:12, Dirk Hohndel wrote:
>
>
>> On Mar 7, 2020, at 5:27 AM, Christof Arnosti > > wrote:
>>
>> Hi Dirk,
>>
>> I did the integration of the Icon HD VID/PID pair, so if the testing
>> is successful I think there is nothing left for me to do before a merge.
>>
>
> I will play with this in a couple of hours and most likely merge your
> changes.
I'm looking forward to leave my laptop at home for my next diving
holiday! :-)
>
>> Someone just tested with an Mares Nemo Wide (Serial < 5), and it
>> did also work.
>>
>
> Excellent.
>
>> Just for clarification about the possible UI changes (now that I'm
>> more awake again), I would envision a workflow like this:
>> - When opening the divecomputer-screen, or pressing the refresh
>> button ("Neu Scannen" in german), get all UsbDevices by issuing
>> UsbManager.getDeviceList(). Use these to populate the connection
>> ("Verbindung") list. (Only show the entries with specified
>> driver-class when this is activated in the settings). I think there
>> has to be done some work in the bt-discovery part so that these two
>> mechanisms can work together.
>>
>
> I'm not sure what you mean by only showing the entries with a
> specified driver class. I thought the driver class is something that
> you would select in that Connection drop down as an alternative to the
> found devices.
> My guess is that on the vast, vast majority of Android devices you
> will only ever get one USB device. Maybe if someone uses a hub for
> some reason (maybe to power the phone while reading dives?) one might
> see more, but in general that would surprise me.
> So we should optimize the user experience for the common case. Which
> means to try and identify the one USB serial device that is connected.
>>
>> - When a device from the connection list is selected, maybe try to
>> guess Vendor / Model by data provided in the UsbDevice-Object. There
>> is already some code in QMLManager::showDownloadPage. I'm not sure
>> how much there can be done since it seems that a lot of devices use
>> the same PID/VIDs.
>>
>
> Correct - I played with that back when working on the Intent code and
> while there are a couple you can explicitly identify, for most that is
> not possible
>
>> - When the download-button is pressed, the UsbDevice-Object of the
>> selected connection (and if selected the name of the driver-class)
>> should be passed to serial_android_usb_open. From there on I can do
>> the work.
>>
>
> So again, you are suggesting to have a second (or actually, fourth?)
> drop down with a driver class?
No, I would keep the existing "connection" dropdown.

My Idea for populating the list would be this:

- Have a setting in the application settings like "Allow usb-serial
driver selection". (since in most cases the driver can be automatically
detected - as you said, most DCs have known PID/VID pairs).
- In the device-dropdown display all found USB devices (as you said,
most likely it's just one).
-> If the Driver-Selection setting is not enabled, just show something
like "Silicon Labs CP2102" per USB device.
-> If the Driver-Selection setting is enabled, show multiple entries per
driver, something like "Silicon Labs CP2102 (autodetect driver)",
"Silicon Labs CP2102 (FTDI)", "Silicon Labs CP2102 (CP21xx)" etc., for
all the driver classes.

Does this make more sense?

>
>> There would probably also have to be done some changes when receiving
>> the USB_DEVICE_ATTACHED intent so that the correct entry of the list
>> is preselected.
>>
>
> I believe so.
>
> /D
Best regards
Christof
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface Mobile: Adding mares USB (cp210x) support; how to proceed

[Stephen Goodall via subsurface]

Will this affect all USB computers with Android? Very exciting!! I had a
look but made no progress (C++ is not something I've worked with so it
would have been a miracle if I had made progress :D )

I've got a Cressi Leonardo and a Suunto Zoop, and an Android 9 phone if you
want me to test those out with any changes. Let me know the branch and I
can build it and test it out

Cheers!

On Sun, 8 Mar 2020, 3:14 am Dirk Hohndel via subsurface, <
subsurface@subsurface-divelog.org> wrote:

>
>
> On Mar 7, 2020, at 5:27 AM, Christof Arnosti  wrote:
>
> Hi Dirk,
>
> I did the integration of the Icon HD VID/PID pair, so if the testing is
> successful I think there is nothing left for me to do before a merge.
>
>
> I will play with this in a couple of hours and most likely merge your
> changes.
>
> Someone just tested with an Mares Nemo Wide (Serial < 5), and it did
> also work.
>
>
> Excellent.
>
> Just for clarification about the possible UI changes (now that I'm more
> awake again), I would envision a workflow like this:
> - When opening the divecomputer-screen, or pressing the refresh button
> ("Neu Scannen" in german), get all UsbDevices by issuing
> UsbManager.getDeviceList(). Use these to populate the connection
> ("Verbindung") list. (Only show the entries with specified driver-class
> when this is activated in the settings). I think there has to be done some
> work in the bt-discovery part so that these two mechanisms can work
> together.
>
>
> I'm not sure what you mean by only showing the entries with a specified
> driver class. I thought the driver class is something that you would select
> in that Connection drop down as an alternative to the found devices.
> My guess is that on the vast, vast majority of Android devices you will
> only ever get one USB device. Maybe if someone uses a hub for some reason
> (maybe to power the phone while reading dives?) one might see more, but in
> general that would surprise me.
> So we should optimize the user experience for the common case. Which means
> to try and identify the one USB serial device that is connected.
>
> - When a device from the connection list is selected, maybe try to guess
> Vendor / Model by data provided in the UsbDevice-Object. There is already
> some code in QMLManager::showDownloadPage. I'm not sure how much there can
> be done since it seems that a lot of devices use the same PID/VIDs.
>
>
> Correct - I played with that back when working on the Intent code and
> while there are a couple you can explicitly identify, for most that is not
> possible
>
> - When the download-button is pressed, the UsbDevice-Object of the
> selected connection (and if selected the name of the driver-class) should
> be passed to serial_android_usb_open. From there on I can do the work.
>
>
> So again, you are suggesting to have a second (or actually, fourth?) drop
> down with a driver class?
>
> There would probably also have to be done some changes when receiving the
> USB_DEVICE_ATTACHED intent so that the correct entry of the list is
> preselected.
>
>
> I believe so.
>
> /D
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: mailing list changes

[Dirk Hohndel via subsurface]

Please have bike shedding festivities about communication mechanisms in the 
Telegram group of your choice.

And please feel free to start a Telegram group for Subsurface. But please don't 
expect any of the main developers to ever show up there.

This development mailing list is and will be on email. If you would rather not 
be on email, that is certainly your choice.

Thanks

/D

> On Mar 7, 2020, at 1:33 AM, tormento via subsurface 
>  wrote:
> 
> Unless you use a SECURE VPN, IP is included in the header or anyway traceable.
> 
> It’s more than enough to have some agency knocking at your door.
> 
> Il giorno sab 7 mar 2020 alle 10:30 Benjamin  > ha scritto:
> Email is not really personally identifiable. Anyone can use a given account 
> at any time. Telegram, Signal, WhatsApp and their ilk are all linked to a 
> telephone number. So that already limits who can use it concurrently. Which 
> means that fingers can be pointed at people more easily. Which tends to make 
> certain people slightly nervous ;)
> 
> On Sat, 7 Mar 2020, 11:26 tormento via subsurface, 
>  > wrote:
> Are you all really talking about crypto when emails travel as plain text? XD
> 
> Il giorno sab 7 mar 2020 alle 09:47 Benjamin  > ha scritto:
> The cryptography in Telegram has already been compromised, as seen in that 
> case in Brazil a short while ago. 
> 
> On Sat, 7 Mar 2020, 10:12 Robert C. Helling via subsurface, 
>  > wrote:
> Hi,
> 
> > Am 07.03.2020 um 00:06 schrieb tormento via subsurface 
> >  > >:
> > 
> > Ever thought about creating a Telegram group?
> 
> Please don’t. Email as a mature technology is far superior to any messenger 
> in terms of archiving, searching, sorting and automated processing. 
> 
> Just my $.02
> Robert
> 
> Ps: wrt telegram: please convince yourself you can trust the people behind 
> telegram before relying on the cryptography they offer. 
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org 
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface 
> 
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org 
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface 
> 
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface Mobile: Adding mares USB (cp210x) support; how to proceed

[Dirk Hohndel via subsurface]

> On Mar 7, 2020, at 5:27 AM, Christof Arnosti  wrote:
> 
> Hi Dirk,
> 
> I did the integration of the Icon HD VID/PID pair, so if the testing is 
> successful I think there is nothing left for me to do before a merge.
> 

I will play with this in a couple of hours and most likely merge your changes.

> Someone just tested with an Mares Nemo Wide (Serial < 5), and it did also 
> work.
> 

Excellent.

> Just for clarification about the possible UI changes (now that I'm more awake 
> again), I would envision a workflow like this:
> - When opening the divecomputer-screen, or pressing the refresh button ("Neu 
> Scannen" in german), get all UsbDevices by issuing 
> UsbManager.getDeviceList(). Use these to populate the connection 
> ("Verbindung") list. (Only show the entries with specified driver-class when 
> this is activated in the settings). I think there has to be done some work in 
> the bt-discovery part so that these two mechanisms can work together.
> 

I'm not sure what you mean by only showing the entries with a specified driver 
class. I thought the driver class is something that you would select in that 
Connection drop down as an alternative to the found devices.
My guess is that on the vast, vast majority of Android devices you will only 
ever get one USB device. Maybe if someone uses a hub for some reason (maybe to 
power the phone while reading dives?) one might see more, but in general that 
would surprise me.
So we should optimize the user experience for the common case. Which means to 
try and identify the one USB serial device that is connected.
> - When a device from the connection list is selected, maybe try to guess 
> Vendor / Model by data provided in the UsbDevice-Object. There is already 
> some code in QMLManager::showDownloadPage. I'm not sure how much there can be 
> done since it seems that a lot of devices use the same PID/VIDs.
> 

Correct - I played with that back when working on the Intent code and while 
there are a couple you can explicitly identify, for most that is not possible

> - When the download-button is pressed, the UsbDevice-Object of the selected 
> connection (and if selected the name of the driver-class) should be passed to 
> serial_android_usb_open. From there on I can do the work.
> 

So again, you are suggesting to have a second (or actually, fourth?) drop down 
with a driver class?

> There would probably also have to be done some changes when receiving the 
> USB_DEVICE_ATTACHED intent so that the correct entry of the list is 
> preselected.
> 

I believe so.

/D___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: mailing list changes

[tormento via subsurface]

When I reply from Gmail I always have to change the address or the mail
will be apparently sent to the person, not to the mailing list.

Il giorno sab 7 mar 2020 alle 14:31 Jef Driesen via subsurface <
subsurface@subsurface-divelog.org> ha scritto:

> On 7/03/2020 13:50, Christof Arnosti via subsurface wrote:
> > Can you explain this a bit more?
> >
> > I think that DKIM / DMARC does exactly what it should: preventing
> modification
> > of mails with "MailFrom" from my domain on-the-fly.
> >
> > I also have SPF configured, which should in theory also lead to a reject
> when my
> > domain is used as MailFrom.
> >
> > With DMARC, if I understand correctly, the mail should only be threated
> as
> > boguous when both of these mechanisms fail at once. This is the case
> when the
> > subsurface-divelog.org list server modifies my mail (breaks DKIM) and
> sends it
> > from it own server (breaks SPF) with MailFrom ~= *@charno.ch.
> >
> > I understand that this leads to problems with mailing lists, but on the
> other
> > hand I would think that replacing the sender address by the mailing list
> > software (like done now on subsurface-divelog.org) should be the right
> way to
> > deal with this problem. Honestly, I'm more curious about why your mail
> client
> > only displays the sender mail-address (but not always? The mail you
> directly
> > received from Benjamin seems fine?) instead of the name in the
> MailFrom-Header.
> >
> > I think that DMARC / DKIM / SPF are a quite important tool in the fight
> against
> > mail spoofing, so I would hate to weaken or disable it.
> >
> > Can you give me some recommendation on how I should configure DMARC /
> DKIM / SPF
> > without breaking spoof-save mailing, but still working with mailinglists
> > configured like subsurface was before?
> There is an import difference between the "From" email header (which is
> displayed by the mail client), and the sender/recipient address ("mail
> from" and
> "rcpt to") used during the smtp communication. For SPF only the latter is
> relevant. So it would be perfectly possible to leave the From header
> intact:
>
> From: Christof Arnosti <...@charno.ch>
>
> and send the mail from the subsurface domain:
>
> MAIL FROM: 
> RCPT TO: 
>
> For SPF everything should be fine because the mail originates from the
> subsurface mail server, and the mail client will show the correct name. Or
> am I
> missing something? I'm certainly not an expert on mail server
> configuration, but
> I do run one too.
>
> For DKIM/DMARC I don't really know.
>
> Jef
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: mailing list changes

[Jef Driesen via subsurface]

On 7/03/2020 13:50, Christof Arnosti via subsurface wrote:

Can you explain this a bit more?

I think that DKIM / DMARC does exactly what it should: preventing modification 
of mails with "MailFrom" from my domain on-the-fly.


I also have SPF configured, which should in theory also lead to a reject when my 
domain is used as MailFrom.


With DMARC, if I understand correctly, the mail should only be threated as 
boguous when both of these mechanisms fail at once. This is the case when the 
subsurface-divelog.org list server modifies my mail (breaks DKIM) and sends it 
from it own server (breaks SPF) with MailFrom ~= *@charno.ch.


I understand that this leads to problems with mailing lists, but on the other 
hand I would think that replacing the sender address by the mailing list 
software (like done now on subsurface-divelog.org) should be the right way to 
deal with this problem. Honestly, I'm more curious about why your mail client 
only displays the sender mail-address (but not always? The mail you directly 
received from Benjamin seems fine?) instead of the name in the MailFrom-Header.


I think that DMARC / DKIM / SPF are a quite important tool in the fight against 
mail spoofing, so I would hate to weaken or disable it.


Can you give me some recommendation on how I should configure DMARC / DKIM / SPF 
without breaking spoof-save mailing, but still working with mailinglists 
configured like subsurface was before?
There is an import difference between the "From" email header (which is 
displayed by the mail client), and the sender/recipient address ("mail from" and 
"rcpt to") used during the smtp communication. For SPF only the latter is 
relevant. So it would be perfectly possible to leave the From header intact:


   From: Christof Arnosti <...@charno.ch>

and send the mail from the subsurface domain:

   MAIL FROM: 
   RCPT TO: 

For SPF everything should be fine because the mail originates from the 
subsurface mail server, and the mail client will show the correct name. Or am I 
missing something? I'm certainly not an expert on mail server configuration, but 
I do run one too.


For DKIM/DMARC I don't really know.

Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface Mobile: Adding mares USB (cp210x) support; how to proceed

[Christof Arnosti via subsurface]

Hi Dirk,

I did the integration of the Icon HD VID/PID pair, so if the testing is
successful I think there is nothing left for me to do before a merge.

Someone just tested with an Mares Nemo Wide (Serial < 5), and it did
also work.

Just for clarification about the possible UI changes (now that I'm more
awake again), I would envision a workflow like this:
- When opening the divecomputer-screen, or pressing the refresh button
("Neu Scannen" in german), get all UsbDevices by issuing
UsbManager.getDeviceList(). Use these to populate the connection
("Verbindung") list. (Only show the entries with specified driver-class
when this is activated in the settings). I think there has to be done
some work in the bt-discovery part so that these two mechanisms can work
together.
- When a device from the connection list is selected, maybe try to guess
Vendor / Model by data provided in the UsbDevice-Object. There is
already some code in QMLManager::showDownloadPage. I'm not sure how much
there can be done since it seems that a lot of devices use the same
PID/VIDs.
- When the download-button is pressed, the UsbDevice-Object of the
selected connection (and if selected the name of the driver-class)
should be passed to serial_android_usb_open. From there on I can do the
work.

There would probably also have to be done some changes when receiving
the USB_DEVICE_ATTACHED intent so that the correct entry of the list is
preselected.

Best regards
Christof

On 07.03.20 02:11, Dirk Hohndel via subsurface wrote:
>
>
>> On Mar 6, 2020, at 5:03 PM, Christof Arnosti > > wrote:
>>> And here you are losing me again :-)
>>> Are you suggesting that we could walk through the list of devices
>>> and try to populate the dropdowns on the download page accordingly?
>>> That sounds like a great idea.
>> Yes, that's exactly what I tried to suggest. Thanks for putting it in
>> understandable words, it's getting late here.
>
> It is indeed.
>
 I didn't consciously check for devices not entered in the
 device_filter.xml, but I entered "my" PID/VID pair quite late in
 the development cycle. I also have seen and used the "ask
 permission" popup which happens when a device not in
 device_filter.xml is used. I will test this tomorrow by removing
 "my" entry from the device_filter.xml.

>>>
>>> Excellent. Should I wait for further updates from you before merging
>>> the current code?
>>
>> Hmm... I'd propose that I add the CdcAcm-driver for the Icon HD
>> VID/PID (if this works then all the PID/VIDs from
>> libdivecomputer.org/drivers.html
>>  are be supported! :-D)
>> tomorrow, and that you then merge the code if everything else is fine.
>>
>
> That sounds excellent to me. I can test this and then merge the PR.
>
>> Work on the UI could be done in a separate branch, and I'm happy to
>> help on the driver side.
>>
>
> That was my plan. I'll do the UI / integration work and we'll figure
> out what's needed on the driver side to make this work.
>
> So exciting!
>
> /D
>
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: mailing list changes

[Robert Helling via subsurface]

Hi,

> On 7. Mar 2020, at 10:25, tormento via subsurface 
>  > wrote:
> 
> Are you all really talking about crypto when emails travel as plain text? XD

sorry, my response was too short. I meant: Messengers are not a good 
replacement for email since they lack features like archiving, sorting, etc.

Messengers have a place (but not as email replacements), in particular if you 
want encrypted in the moment communication. If you want to use and rely on 
encryption, choose your tools wisely.

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: mailing list changes

[tormento via subsurface]

Unless you use a SECURE VPN, IP is included in the header or anyway
traceable.

It’s more than enough to have some agency knocking at your door.

Il giorno sab 7 mar 2020 alle 10:30 Benjamin  ha scritto:

> Email is not really personally identifiable. Anyone can use a given
> account at any time. Telegram, Signal, WhatsApp and their ilk are all
> linked to a telephone number. So that already limits who can use it
> concurrently. Which means that fingers can be pointed at people more
> easily. Which tends to make certain people slightly nervous ;)
>
> On Sat, 7 Mar 2020, 11:26 tormento via subsurface, <
> subsurface@subsurface-divelog.org> wrote:
>
>> Are you all really talking about crypto when emails travel as plain text?
>> XD
>>
>> Il giorno sab 7 mar 2020 alle 09:47 Benjamin  ha
>> scritto:
>>
>>> The cryptography in Telegram has already been compromised, as seen in
>>> that case in Brazil a short while ago.
>>>
>>> On Sat, 7 Mar 2020, 10:12 Robert C. Helling via subsurface, <
>>> subsurface@subsurface-divelog.org> wrote:
>>>
 Hi,

 > Am 07.03.2020 um 00:06 schrieb tormento via subsurface <
 subsurface@subsurface-divelog.org>:
 >
 > Ever thought about creating a Telegram group?

 Please don’t. Email as a mature technology is far superior to any
 messenger in terms of archiving, searching, sorting and automated
 processing.

 Just my $.02
 Robert

 Ps: wrt telegram: please convince yourself you can trust the people
 behind telegram before relying on the cryptography they offer.
 ___
 subsurface mailing list
 subsurface@subsurface-divelog.org
 http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

>>> ___
>> subsurface mailing list
>> subsurface@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: mailing list changes

[Benjamin via subsurface]

Email is not really personally identifiable. Anyone can use a given account
at any time. Telegram, Signal, WhatsApp and their ilk are all linked to a
telephone number. So that already limits who can use it concurrently. Which
means that fingers can be pointed at people more easily. Which tends to
make certain people slightly nervous ;)

On Sat, 7 Mar 2020, 11:26 tormento via subsurface, <
subsurface@subsurface-divelog.org> wrote:

> Are you all really talking about crypto when emails travel as plain text?
> XD
>
> Il giorno sab 7 mar 2020 alle 09:47 Benjamin  ha
> scritto:
>
>> The cryptography in Telegram has already been compromised, as seen in
>> that case in Brazil a short while ago.
>>
>> On Sat, 7 Mar 2020, 10:12 Robert C. Helling via subsurface, <
>> subsurface@subsurface-divelog.org> wrote:
>>
>>> Hi,
>>>
>>> > Am 07.03.2020 um 00:06 schrieb tormento via subsurface <
>>> subsurface@subsurface-divelog.org>:
>>> >
>>> > Ever thought about creating a Telegram group?
>>>
>>> Please don’t. Email as a mature technology is far superior to any
>>> messenger in terms of archiving, searching, sorting and automated
>>> processing.
>>>
>>> Just my $.02
>>> Robert
>>>
>>> Ps: wrt telegram: please convince yourself you can trust the people
>>> behind telegram before relying on the cryptography they offer.
>>> ___
>>> subsurface mailing list
>>> subsurface@subsurface-divelog.org
>>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>>
>> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: mailing list changes

[tormento via subsurface]

Are you all really talking about crypto when emails travel as plain text? XD

Il giorno sab 7 mar 2020 alle 09:47 Benjamin  ha scritto:

> The cryptography in Telegram has already been compromised, as seen in that
> case in Brazil a short while ago.
>
> On Sat, 7 Mar 2020, 10:12 Robert C. Helling via subsurface, <
> subsurface@subsurface-divelog.org> wrote:
>
>> Hi,
>>
>> > Am 07.03.2020 um 00:06 schrieb tormento via subsurface <
>> subsurface@subsurface-divelog.org>:
>> >
>> > Ever thought about creating a Telegram group?
>>
>> Please don’t. Email as a mature technology is far superior to any
>> messenger in terms of archiving, searching, sorting and automated
>> processing.
>>
>> Just my $.02
>> Robert
>>
>> Ps: wrt telegram: please convince yourself you can trust the people
>> behind telegram before relying on the cryptography they offer.
>> ___
>> subsurface mailing list
>> subsurface@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: mailing list changes

[Benjamin via subsurface]

The cryptography in Telegram has already been compromised, as seen in that
case in Brazil a short while ago.

On Sat, 7 Mar 2020, 10:12 Robert C. Helling via subsurface, <
subsurface@subsurface-divelog.org> wrote:

> Hi,
>
> > Am 07.03.2020 um 00:06 schrieb tormento via subsurface <
> subsurface@subsurface-divelog.org>:
> >
> > Ever thought about creating a Telegram group?
>
> Please don’t. Email as a mature technology is far superior to any
> messenger in terms of archiving, searching, sorting and automated
> processing.
>
> Just my $.02
> Robert
>
> Ps: wrt telegram: please convince yourself you can trust the people behind
> telegram before relying on the cryptography they offer.
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: mailing list changes

[Robert C. Helling via subsurface]

Hi,

> Am 07.03.2020 um 00:06 schrieb tormento via subsurface 
> :
> 
> Ever thought about creating a Telegram group?

Please don’t. Email as a mature technology is far superior to any messenger in 
terms of archiving, searching, sorting and automated processing. 

Just my $.02
Robert

Ps: wrt telegram: please convince yourself you can trust the people behind 
telegram before relying on the cryptography they offer. 
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface