Re: [Interest] android: QStorageInfo::mountedVolumes does not "see" SD card

[Alexander Dyagilev]

Hello,

Thanks for the response! Yes, I was using 5.11.3. Tried 5.12.5 - works 
fine now.



On 9/16/2019 6:02 PM, Thiago Macieira wrote:

On Monday, 16 September 2019 07:56:20 PDT Alexander Dyagilev wrote:

On my android 9.0 phone it returns one "/" volume only. But I have SD
card installed.

Is it a bug? Should I file a report?

There was a bug parsing the mountpoints that affected Android, but I think it
was fixed a while ago. Are you using the latest Qt (5.13.1) in this test?


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.9 and OpenSSL 1.1?

[Thiago Macieira]

On Monday, 16 September 2019 11:48:20 PDT Giuseppe D'Angelo via Interest 
wrote:
> And this again just mentions that earlier SSL versions had security
> vulnerabilities. It does not sustain the claim that there is NO version
> which is secure.
> 
> (As Thiago has already reminded, we're way past the point where we do
> get to prove mathematically the correctness and the security of our
> code; instead we rely on expert research, responsible disclosure and
> quick fix of any issue that may have been found.)

The security claim here is relative.

There is no currently known attack against SSL/TLS. That does not imply it's 
mathematically proven to be safe. In all likelihood, there will be issues 
found. If by that you mean that it's not secure, then yes: it's not secure 
because there'll likely be a new vulnerability discovered.

However, until that happens, it's as secure as we can make anything.

I should also point out that so far, none of the successful attacks against 
SSL/TLS are attacking the encryption. The attacks usually come via a side-
channel or some other weak component of the structure. Examples are the 
Heartbleed, the earlier attack against compression, the renegotiation attack. 
More frequently, hacks are attacking social engineering, like weak passwords, 
unsecured or improperly-secured systems. It's believed the Stuxnet attack 
against Iran's nuclear energy labs was started by dropping USB flash drives in 
the parking lot.

And yet, this is the best we've got. What's the alternative? No encryption and 
no authentication?

Even the only encryption method mathematically proven to be resistant to 
direct attacks (one-time pads) is vulnerable to side-channel attacks. The OTP 
leaks and all your data is readable. If the random generator you used to 
create it in the first place can be predicted, you've also got a problem (for 
example, by inspecting the initial TCP sequence values that your system 
sends).

I'll agree with Roland that "use SSL, you're safe" is not a factually correct 
statement. A simple debug-mode "ignoreSslErrors()" left in your code kicks the 
door wide open to attackers. SSL is a component of your security architecture, 
but not the only one.

But I'll also agree with Peppe that SSL/TLS is as secure as we can make it. 
Claiming otherwise, claiming that there are attacks that slice through up-to-
date and well-maintained installations like a hot knife through butter, 
without offering proof, is beyond disingenuous. It's positively irresponsible.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.9 and OpenSSL 1.1?

[Giuseppe D'Angelo via Interest]

On 16/09/2019 18:51, Roland Hughes wrote:


On 9/16/19 10:41 AM, Giuseppe D'Angelo wrote:

On 16/09/2019 14:44, Roland Hughes wrote:

On 9/16/19 5:00 AM,interest-requ...@qt-project.org  wrote:

Il 14/09/19 14:53, Roland Hughes ha scritto:

Please keep in mind there is no version of SSL which is secure.

Do you have any reference/source for this (quite extraordinary) claim?

You know, for you it wouldn't matter. It would be a link and you are
incapable of actually clicking then reading anything which doesn't
support your opinion.

So, personal insults right off the bat?

Not insults, factual history. You've even flamed about links in messages
in this very thread.

There are numerous packages on the market which
cut through SSL like a hot knife through butter.

Any link to ANY of those?


This is the leg work __you__ should be doing before writing your first
line of code and before making any claim that SSL is secure.


It doesn't work like this. YOU made the claim that SSL is not secure. 
Specifically, that it's as secure as


hanging a CLOSED sign on the unlocked door to a 
jewelry store having $20 million in inventory sitting in the cases 
without an alarm system.


So YOU now have to provide the references to support that claim.




https://techxplore.com/news/2019-03-cybersecurity-dark-web-exposes-vulnerability.html

Actual report the article is based on

https://www.venafi.com/sites/default/files/2019-02/Dark-Web-WP.pdf


This is exclusively about PKIs. It doesn't show any breach whatsoever of 
SSL.





Here's some historical ones from Cisco. A bit dated but shows just how
thriving successful attacks have been through SSL.

https://blogs.cisco.com/security/breach-crime-and-blackhat


This actually puts SSL in a positive light, showing only THREE attacks 
against it. At least RFC 7457 shows more.




More

https://www.semrush.com/blog/https-a-modern-false-sense-of-security


And this again just mentions that earlier SSL versions had security 
vulnerabilities. It does not sustain the claim that there is NO version 
which is secure.


(As Thiago has already reminded, we're way past the point where we do 
get to prove mathematically the correctness and the security of our 
code; instead we rely on expert research, responsible disclosure and 
quick fix of any issue that may have been found.)




"60 Minutes" did a
piece on the best known and most financially successful one but some
sources say there are around a dozen packages playing at the same level.
Here's the link which was provided before and I'm sure you didn't bother
to follow prior to responding.

https://www.cbsnews.com/news/interview-with-ceo-of-nso-group-spyware-maker-fighting-terror-khashoggi-murder-and-saudi-arabia-60-minutes-2019-08-18/

The link does not talk about breaking SSL. The link is about spyware for
smartphones. SSL is actually never mentioned, not to mention of course
breaking it.


One of the primary ways it does it is by breaching SSL which is the
easiest entry point. The second entry point is via that little
bot/virus/malware/whatever-called-this-week they attach to the phishing
email.


Where exactly in the video is "breaching SSL" stated? This is pure 
speculation, and very likely to be false too (you don't need to breach 
SSL to plant malware. You don't even need SSL in the first place!).





Please also keep in mind the big systems are moving towards a TCP/IP
software appliance within the OS. No application will be able to create
or open a port. No application will be able to choose/define the
transport layer security. They will open a logical-resource-handle
provided by the OS and the systems manager will configure if that
resource is I, O, or I/O as well as what the transport level protocols
are. Eventually (within 5 years of adoption) this will be forced out
into the IoT and lesser devices world as well.

So long for the "backward compatibility is paramount" promise then.

That would only be for the hokey code which came from the *nix world.

And Windows.

which took it from the *nix world if memory serves.

For the code which didn't come from a world that did it wrong it is 100%
backwardly compatible because that is exactly how we did network
communications. In other words all of the software developed_on_  those
platforms and_for_  those platforms will be fine. What will be going
away are the *nix TCP/IP library functions of C/C++ because they are a
massive security nightmare. There was a time when marketing bowed to the
pressure from companies which only wanted "free" software on their
million plus dollar platform, but that has lead to security catastrophe
after security catastrophe. Now they are in the process of locking them
back down and just letting people whine an snivel about *nix package not
being available on the platform.

So we're talking about non-Unix, non-Windows, non-Apple platforms. I.e.
roughly about 0% of the current market share of Qt. What are Qt users
(the people who read this very mailing list) 

Re: [Interest] Qt 5.9 and OpenSSL 1.1?

[Roland Hughes]

On 9/16/19 10:41 AM, Giuseppe D'Angelo wrote:

On 16/09/2019 14:44, Roland Hughes wrote:

On 9/16/19 5:00 AM,interest-requ...@qt-project.org  wrote:

Il 14/09/19 14:53, Roland Hughes ha scritto:

Please keep in mind there is no version of SSL which is secure.

Do you have any reference/source for this (quite extraordinary) claim?

You know, for you it wouldn't matter. It would be a link and you are
incapable of actually clicking then reading anything which doesn't
support your opinion.

So, personal insults right off the bat?
Not insults, factual history. You've even flamed about links in messages 
in this very thread.

There are numerous packages on the market which
cut through SSL like a hot knife through butter.

Any link to ANY of those?


This is the leg work __you__ should be doing before writing your first 
line of code and before making any claim that SSL is secure.


https://techxplore.com/news/2019-03-cybersecurity-dark-web-exposes-vulnerability.html

Actual report the article is based on

https://www.venafi.com/sites/default/files/2019-02/Dark-Web-WP.pdf


Here's some historical ones from Cisco. A bit dated but shows just how 
thriving successful attacks have been through SSL.


https://blogs.cisco.com/security/breach-crime-and-blackhat

More

https://www.semrush.com/blog/https-a-modern-false-sense-of-security


"60 Minutes" did a
piece on the best known and most financially successful one but some
sources say there are around a dozen packages playing at the same level.
Here's the link which was provided before and I'm sure you didn't bother
to follow prior to responding.

https://www.cbsnews.com/news/interview-with-ceo-of-nso-group-spyware-maker-fighting-terror-khashoggi-murder-and-saudi-arabia-60-minutes-2019-08-18/

The link does not talk about breaking SSL. The link is about spyware for
smartphones. SSL is actually never mentioned, not to mention of course
breaking it.


One of the primary ways it does it is by breaching SSL which is the 
easiest entry point. The second entry point is via that little 
bot/virus/malware/whatever-called-this-week they attach to the phishing 
email.



I'll reinstate: where is the evidence supporting the claim that "there
is no version of SSL which is secure"?

This is a super-strong claim on a mailing list read by Qt users, who are
using SSL in their products, who are relying on Qt to do the right thing
when it comes to security technologies (and Qt offers SSL-related
facilities).




Please also keep in mind the big systems are moving towards a TCP/IP
software appliance within the OS. No application will be able to create
or open a port. No application will be able to choose/define the
transport layer security. They will open a logical-resource-handle
provided by the OS and the systems manager will configure if that
resource is I, O, or I/O as well as what the transport level protocols
are. Eventually (within 5 years of adoption) this will be forced out
into the IoT and lesser devices world as well.

So long for the "backward compatibility is paramount" promise then.

That would only be for the hokey code which came from the *nix world.

And Windows.

which took it from the *nix world if memory serves.

For the code which didn't come from a world that did it wrong it is 100%
backwardly compatible because that is exactly how we did network
communications. In other words all of the software developed_on_  those
platforms and_for_  those platforms will be fine. What will be going
away are the *nix TCP/IP library functions of C/C++ because they are a
massive security nightmare. There was a time when marketing bowed to the
pressure from companies which only wanted "free" software on their
million plus dollar platform, but that has lead to security catastrophe
after security catastrophe. Now they are in the process of locking them
back down and just letting people whine an snivel about *nix package not
being available on the platform.

So we're talking about non-Unix, non-Windows, non-Apple platforms. I.e.
roughly about 0% of the current market share of Qt. What are Qt users
(the people who read this very mailing list) going to do with this
useless information?


These are the business engines the embedded systems many of us create in 
the industrial and medical worlds which our devices will have to play 
nice with or some other device will be purchased which isn't written 
with Qt.


Don't be so quick to say non-Unix because that is not correct. Tru64 had 
it and that got rolled into HP-UX as well as into Non-Stop. It was also 
added into AIX at some point. It even existed on the original Windows NT 
before the tiny DOS brains at Microsoft stripped NT back to nothing but DOS.


The selling point in the world of the Big Dogs is now bullet proof 
security. An $80 x86 CPU running a "free" OS on a rack/blade somewhere 
is going to cost you north of $60 million, possibly $425 million


https://www.ftc.gov/enforcement/cases-proceedings/refunds/equifax-data-breach-sett

Re: [Interest] android: QStorageInfo::mountedVolumes does not "see" SD card

[Shawn Rutledge]

On 16 Sep 2019, at 16:56, Alexander Dyagilev 
mailto:alervd...@gmail.com>> wrote:

On my android 9.0 phone it returns one "/" volume only. But I have SD card 
installed.

Is it a bug? Should I file a report?

Back when we implemented QStorageInfo it looked like this for me on one device 
that I tested (not sure if that was after the patches were actually committed 
though):

http://ecloud.org/misc/android-volumes.png

I wonder if they have changed how mounting is done in newer Android versions.  
(Yeah I could build that example and test again.  It’s 
qtbase/examples/widgets/itemviews/storageview BTW.)

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] android: QStorageInfo::mountedVolumes does not "see" SD card

[Thiago Macieira]

On Monday, 16 September 2019 07:56:20 PDT Alexander Dyagilev wrote:
> On my android 9.0 phone it returns one "/" volume only. But I have SD
> card installed.
> 
> Is it a bug? Should I file a report?

There was a bug parsing the mountpoints that affected Android, but I think it 
was fixed a while ago. Are you using the latest Qt (5.13.1) in this test?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] android: QStorageInfo::mountedVolumes does not "see" SD card

[Alexander Dyagilev]

On my android 9.0 phone it returns one "/" volume only. But I have SD 
card installed.


Is it a bug? Should I file a report?

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] mac app crashes if you plug in another monitor

[Giuseppe D'Angelo via Interest]

Hi,

On 13/09/2019 16:49, David M. Cotter wrote:

this seems unexpected


Not a mac user myself, but if you have a minimal testcase, please 
consider submitting a bug report.


HTH,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] mac app crashes if you plug in another monitor

[Jason H]

I too was suprised by Vadim's reply. Often there is a dicsussion here before deciding it is a bug or operator error or something else. Vadim's suggested use of going straight to the bug tracker does not seem to fit with the purpose of this list. 

 

FWIW, I am on mac (2016 MBPro) with two external monitors that I undock with Qt apps running and have never had that problem.

 

 

Sent: Sunday, September 15, 2019 at 10:52 PM
From: "David M. Cotter" 
To: "Vadim Peretokin" , Interest 
Subject: Re: [Interest] mac app crashes if you plug in another monitor


I guess i'm surprised you personally took it as a "complaint"
 

but perhaps i wasn't clear enough myself.  my intention was to ask: are other people running into this?  is there something i perhaps didn't configure correctly? would others concur that this is a bug and should be filed?

 

i'm assuming from your reply that you must have reproduced the problem locally, so you concur it is a bug.

 

-dave
 

On Sep 14, 2019, at 6:40 AM, Vadim Peretokin  wrote:
 


The mailing list isn't appropriate for complaints. File a bug report like everyone else, or contact your Qt support if you're on the commercial edition. Thanks!
 


On Fri, 13 Sep. 2019, 5:24 pm David M. Cotter,  wrote:


*I* am not doing anything.  this is the Qt framework
 

On Sep 13, 2019, at 8:01 AM, Jérôme Godbout  wrote:
 



Are you updating the CocoaScreen from a different thread then the main main thread?

 

 



From: Interest  On Behalf Of David M. Cotter
Sent: September 13, 2019 10:49 AM
To: Interest 
Subject: [Interest] mac app crashes if you plug in another monitor



 


this seems unexpected



 








___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest





___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest




___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Interest Digest, Vol 96, Issue 17

[Giuseppe D'Angelo via Interest]

On 16/09/2019 14:44, Roland Hughes wrote:


On 9/16/19 5:00 AM, interest-requ...@qt-project.org wrote:

Il 14/09/19 14:53, Roland Hughes ha scritto:

Please keep in mind there is no version of SSL which is secure.

Do you have any reference/source for this (quite extraordinary) claim?


You know, for you it wouldn't matter. It would be a link and you are
incapable of actually clicking then reading anything which doesn't
support your opinion. 


So, personal insults right off the bat?



There are numerous packages on the market which
cut through SSL like a hot knife through butter.


Any link to ANY of those?



"60 Minutes" did a
piece on the best known and most financially successful one but some
sources say there are around a dozen packages playing at the same level.
Here's the link which was provided before and I'm sure you didn't bother
to follow prior to responding.

https://www.cbsnews.com/news/interview-with-ceo-of-nso-group-spyware-maker-fighting-terror-khashoggi-murder-and-saudi-arabia-60-minutes-2019-08-18/


The link does not talk about breaking SSL. The link is about spyware for 
smartphones. SSL is actually never mentioned, not to mention of course 
breaking it.



I'll reinstate: where is the evidence supporting the claim that "there 
is no version of SSL which is secure"?


This is a super-strong claim on a mailing list read by Qt users, who are 
using SSL in their products, who are relying on Qt to do the right thing 
when it comes to security technologies (and Qt offers SSL-related 
facilities).







Please also keep in mind the big systems are moving towards a TCP/IP
software appliance within the OS. No application will be able to create
or open a port. No application will be able to choose/define the
transport layer security. They will open a logical-resource-handle
provided by the OS and the systems manager will configure if that
resource is I, O, or I/O as well as what the transport level protocols
are. Eventually (within 5 years of adoption) this will be forced out
into the IoT and lesser devices world as well.

So long for the "backward compatibility is paramount" promise then.


That would only be for the hokey code which came from the *nix world.


And Windows.



For the code which didn't come from a world that did it wrong it is 100%
backwardly compatible because that is exactly how we did network
communications. In other words all of the software developed _on_ those
platforms and _for_ those platforms will be fine. What will be going
away are the *nix TCP/IP library functions of C/C++ because they are a
massive security nightmare. There was a time when marketing bowed to the
pressure from companies which only wanted "free" software on their
million plus dollar platform, but that has lead to security catastrophe
after security catastrophe. Now they are in the process of locking them
back down and just letting people whine an snivel about *nix package not
being available on the platform.


So we're talking about non-Unix, non-Windows, non-Apple platforms. I.e. 
roughly about 0% of the current market share of Qt. What are Qt users 
(the people who read this very mailing list) going to do with this 
useless information?


--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Interest Digest, Vol 96, Issue 17

[Roland Hughes]

On 9/16/19 5:00 AM, interest-requ...@qt-project.org wrote:

Il 14/09/19 14:53, Roland Hughes ha scritto:

Please keep in mind there is no version of SSL which is secure.

Do you have any reference/source for this (quite extraordinary) claim?


You know, for you it wouldn't matter. It would be a link and you are 
incapable of actually clicking then reading anything which doesn't 
support your opinion.  There are numerous packages on the market which 
cut through SSL like a hot knife through butter. "60 Minutes" did a 
piece on the best known and most financially successful one but some 
sources say there are around a dozen packages playing at the same level. 
Here's the link which was provided before and I'm sure you didn't bother 
to follow prior to responding.


https://www.cbsnews.com/news/interview-with-ceo-of-nso-group-spyware-maker-fighting-terror-khashoggi-murder-and-saudi-arabia-60-minutes-2019-08-18/



Please also keep in mind the big systems are moving towards a TCP/IP
software appliance within the OS. No application will be able to create
or open a port. No application will be able to choose/define the
transport layer security. They will open a logical-resource-handle
provided by the OS and the systems manager will configure if that
resource is I, O, or I/O as well as what the transport level protocols
are. Eventually (within 5 years of adoption) this will be forced out
into the IoT and lesser devices world as well.

So long for the "backward compatibility is paramount" promise then.


That would only be for the hokey code which came from the *nix world. 
For the code which didn't come from a world that did it wrong it is 100% 
backwardly compatible because that is exactly how we did network 
communications. In other words all of the software developed _on_ those 
platforms and _for_ those platforms will be fine. What will be going 
away are the *nix TCP/IP library functions of C/C++ because they are a 
massive security nightmare. There was a time when marketing bowed to the 
pressure from companies which only wanted "free" software on their 
million plus dollar platform, but that has lead to security catastrophe 
after security catastrophe. Now they are in the process of locking them 
back down and just letting people whine an snivel about *nix package not 
being available on the platform.



--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest