Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[Vadim Peretokin]

Thanks for this - mind pasting it as a gist for easy access?

On Wed, Jul 10, 2019 at 9:59 PM Elvis Stansvik  wrote:

> Den ons 10 juli 2019 kl 21:44 skrev Elvis Stansvik :
> >
> > Den ons 10 juli 2019 kl 21:20 skrev Adam Light :
> > >
> > >
> > >
> > > On Wed, Jul 10, 2019 at 2:28 AM Elvis Stansvik 
> wrote:
> > >>
> > >>
> > >> With "work around" do you mean from the user POV (e.g. somehow
> > >> disabling Gatekeeper, or Ctrl+Open, or something else) or from a
> > >> developer POV (so, having to notarize)?
> > >>
> > >
> > > Instead of repeating myself here, please see my comment at
> https://bugreports.qt.io/browse/QTBUG-73398?focusedCommentId=468111=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-468111
> which explains what I mean by "work around". I just added screen shots of
> the dialogs I mentioned in that comment so it's clear what the user sees.
> > >
> > >>
> > >> I'd like to know if there is some reasonably simple way for users to
> > >> get around the requirement. We will not be able to notarize every
> > >> build we do, because of the time it takes. But at the same time we,
> > >> and our testers, must be able to test random builds from Git (we build
> > >> a .dmg for every commit) to try out in-progress features/bug fixes...
> > >> So I really hope there will be some way for the user to get around the
> > >> notarization requirement.
> > >
> > >
> > > Notarization doesn't take more than a few minutes (in my limited
> experience) but it's a hassle to script the process. Your build machines
> and possibly your testers will not need to have a notarized application
> because, as I understand it, notarization is not required if the
> application does not have a quarantine flag. If it's been downloaded via a
> standard web browser, it should have the flag. But if it was built on the
> machine, or if it was transferred from another machine using something like
> curl, rsync, etc. then it is unlikely to have the quarantine flag.
> >
> > Yes, looking at our last tagged release build, the notarization step
> > took 3 minutes 58 seconds.That's a doubling of our normal build time
> > though, which is why we're hesitant to do it on every commit. That,
> > and also I guess Apple don't really want people doing this anyway.
> >
> > Our testers normally pull the build artifacts using their web browser,
> > so the downloaded .dmg will be quarantined. We could tell them to curl
> > it of course, but we'd like to keep it as simple as possible for them
> > to test a feature/bugfix in progress, and asking them to use a
> > dedicated download tool goes against that.
> >
> > Scripting the notarization wasn't the painful thing. I made a quick
> > Python script that does it, and it has worked fine since then. What
>
> This is the snippet, in case someone else finds it useful (note that
> the --primary-bundle-id flag to altool is hard-coded in the script, so
> you'll want to edit that):
>
> #!/usr/bin/env python3
> #
> # Notarize a file
> #
> # Usage: notarize-macos.py   
> #
>
> from argparse import ArgumentParser
> from subprocess import check_output
> from plistlib import loads
> from time import sleep
>
>
> def main():
> parser = ArgumentParser()
> parser.add_argument('username', help='Apple ID user')
> parser.add_argument('password', help='Apple ID password')
> parser.add_argument('path', help='File to be notarized (e.g. .dmg)')
> args = parser.parse_args()
>
> print('requesting notarization of {}...'.format(args.path))
>
> request_uuid = loads(check_output([
> 'xcrun',
> 'altool',
> '--notarize-app',
> '--primary-bundle-id', 'com.yourdomain.yourapp.dmg',
> '--username', args.username,
> '--password', args.password,
> '--file', args.path,
> '--output-format', 'xml'
> ]))['notarization-upload']['RequestUUID']
>
> for i in range(200):
> response = loads(check_output([
> 'xcrun',
> 'altool',
> '--notarization-info', request_uuid,
> '--username', args.username,
> '--password', args.password,
> '--output-format', 'xml'
> ]))
> if response['notarization-info']['Status'] == 'success':
> print('notarization succeeded, see
> {}'.format(response['notarization-info']['LogFileURL']))
> print('stapling notarization to {}'.format(args.path))
> print(check_output(['xcrun', 'stapler', 'staple',
> args.path]).decode('utf-8'))
> return
> if response['notarization-info']['Status'] == 'invalid':
> raise RuntimeError('notarization failed, response
> was\n{}'.format(response))
> sleep(3)
>
> raise RuntimeError('notarization timed out, last response
> was\n{}'.format(response))
>
>
> if __name__ == '__main__':
> main()
>
> > bothers me is if it will make it harder for our testers. I wish Apple
> > could state clearly whether the 

Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[Elvis Stansvik]

Den ons 10 juli 2019 kl 21:44 skrev Elvis Stansvik :
>
> Den ons 10 juli 2019 kl 21:20 skrev Adam Light :
> >
> >
> >
> > On Wed, Jul 10, 2019 at 2:28 AM Elvis Stansvik  wrote:
> >>
> >>
> >> With "work around" do you mean from the user POV (e.g. somehow
> >> disabling Gatekeeper, or Ctrl+Open, or something else) or from a
> >> developer POV (so, having to notarize)?
> >>
> >
> > Instead of repeating myself here, please see my comment at 
> > https://bugreports.qt.io/browse/QTBUG-73398?focusedCommentId=468111=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-468111
> >  which explains what I mean by "work around". I just added screen shots of 
> > the dialogs I mentioned in that comment so it's clear what the user sees.
> >
> >>
> >> I'd like to know if there is some reasonably simple way for users to
> >> get around the requirement. We will not be able to notarize every
> >> build we do, because of the time it takes. But at the same time we,
> >> and our testers, must be able to test random builds from Git (we build
> >> a .dmg for every commit) to try out in-progress features/bug fixes...
> >> So I really hope there will be some way for the user to get around the
> >> notarization requirement.
> >
> >
> > Notarization doesn't take more than a few minutes (in my limited 
> > experience) but it's a hassle to script the process. Your build machines 
> > and possibly your testers will not need to have a notarized application 
> > because, as I understand it, notarization is not required if the 
> > application does not have a quarantine flag. If it's been downloaded via a 
> > standard web browser, it should have the flag. But if it was built on the 
> > machine, or if it was transferred from another machine using something like 
> > curl, rsync, etc. then it is unlikely to have the quarantine flag.
>
> Yes, looking at our last tagged release build, the notarization step
> took 3 minutes 58 seconds.That's a doubling of our normal build time
> though, which is why we're hesitant to do it on every commit. That,
> and also I guess Apple don't really want people doing this anyway.
>
> Our testers normally pull the build artifacts using their web browser,
> so the downloaded .dmg will be quarantined. We could tell them to curl
> it of course, but we'd like to keep it as simple as possible for them
> to test a feature/bugfix in progress, and asking them to use a
> dedicated download tool goes against that.
>
> Scripting the notarization wasn't the painful thing. I made a quick
> Python script that does it, and it has worked fine since then. What

This is the snippet, in case someone else finds it useful (note that
the --primary-bundle-id flag to altool is hard-coded in the script, so
you'll want to edit that):

#!/usr/bin/env python3
#
# Notarize a file
#
# Usage: notarize-macos.py   
#

from argparse import ArgumentParser
from subprocess import check_output
from plistlib import loads
from time import sleep


def main():
parser = ArgumentParser()
parser.add_argument('username', help='Apple ID user')
parser.add_argument('password', help='Apple ID password')
parser.add_argument('path', help='File to be notarized (e.g. .dmg)')
args = parser.parse_args()

print('requesting notarization of {}...'.format(args.path))

request_uuid = loads(check_output([
'xcrun',
'altool',
'--notarize-app',
'--primary-bundle-id', 'com.yourdomain.yourapp.dmg',
'--username', args.username,
'--password', args.password,
'--file', args.path,
'--output-format', 'xml'
]))['notarization-upload']['RequestUUID']

for i in range(200):
response = loads(check_output([
'xcrun',
'altool',
'--notarization-info', request_uuid,
'--username', args.username,
'--password', args.password,
'--output-format', 'xml'
]))
if response['notarization-info']['Status'] == 'success':
print('notarization succeeded, see
{}'.format(response['notarization-info']['LogFileURL']))
print('stapling notarization to {}'.format(args.path))
print(check_output(['xcrun', 'stapler', 'staple',
args.path]).decode('utf-8'))
return
if response['notarization-info']['Status'] == 'invalid':
raise RuntimeError('notarization failed, response
was\n{}'.format(response))
sleep(3)

raise RuntimeError('notarization timed out, last response
was\n{}'.format(response))


if __name__ == '__main__':
main()

> bothers me is if it will make it harder for our testers. I wish Apple
> could state clearly whether the user will be allowed to override this
> check (à la Ctrl-click -> Open instead of doubleclicking, which you
> can use to bypass certificate verification).
>
> Elvis
>
> >
> > Of course, it is possible that in the future the quarantine flag will not 
> > control whether the notarization check 

Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[Elvis Stansvik]

Den ons 10 juli 2019 kl 21:20 skrev Adam Light :
>
>
>
> On Wed, Jul 10, 2019 at 2:28 AM Elvis Stansvik  wrote:
>>
>>
>> With "work around" do you mean from the user POV (e.g. somehow
>> disabling Gatekeeper, or Ctrl+Open, or something else) or from a
>> developer POV (so, having to notarize)?
>>
>
> Instead of repeating myself here, please see my comment at 
> https://bugreports.qt.io/browse/QTBUG-73398?focusedCommentId=468111=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-468111
>  which explains what I mean by "work around". I just added screen shots of 
> the dialogs I mentioned in that comment so it's clear what the user sees.
>
>>
>> I'd like to know if there is some reasonably simple way for users to
>> get around the requirement. We will not be able to notarize every
>> build we do, because of the time it takes. But at the same time we,
>> and our testers, must be able to test random builds from Git (we build
>> a .dmg for every commit) to try out in-progress features/bug fixes...
>> So I really hope there will be some way for the user to get around the
>> notarization requirement.
>
>
> Notarization doesn't take more than a few minutes (in my limited experience) 
> but it's a hassle to script the process. Your build machines and possibly 
> your testers will not need to have a notarized application because, as I 
> understand it, notarization is not required if the application does not have 
> a quarantine flag. If it's been downloaded via a standard web browser, it 
> should have the flag. But if it was built on the machine, or if it was 
> transferred from another machine using something like curl, rsync, etc. then 
> it is unlikely to have the quarantine flag.

Yes, looking at our last tagged release build, the notarization step
took 3 minutes 58 seconds.That's a doubling of our normal build time
though, which is why we're hesitant to do it on every commit. That,
and also I guess Apple don't really want people doing this anyway.

Our testers normally pull the build artifacts using their web browser,
so the downloaded .dmg will be quarantined. We could tell them to curl
it of course, but we'd like to keep it as simple as possible for them
to test a feature/bugfix in progress, and asking them to use a
dedicated download tool goes against that.

Scripting the notarization wasn't the painful thing. I made a quick
Python script that does it, and it has worked fine since then. What
bothers me is if it will make it harder for our testers. I wish Apple
could state clearly whether the user will be allowed to override this
check (à la Ctrl-click -> Open instead of doubleclicking, which you
can use to bypass certificate verification).

Elvis

>
> Of course, it is possible that in the future the quarantine flag will not 
> control whether the notarization check happens, so what I said in the 
> paragraph above may change.
>
> Adam
>
> ___
> 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] notarizing builds for Mac - enabling hardened runtime

[Adam Light]

On Wed, Jul 10, 2019 at 9:17 AM coroberti .  wrote:

> Adam,
> Could you please provide more details about notarization without runtime
> hardening by using SDK 10.13?
> Specifically, which Xcode version was used and at which Mac OS?
> Thanks,
>
>
See
https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution.
Look at the paragraph after the bullet list in the Prepare Your Software
for Notarization section.

I have successfully notarized our application that is built and code signed
with Xcode 9 on macOS 10.13. I did the notarization of the .dmg itself on a
different machine running 10.14 and Xcode 10. The application does not use
hardened runtime.

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

Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[Adam Light]

On Wed, Jul 10, 2019 at 2:28 AM Elvis Stansvik  wrote:

>
> With "work around" do you mean from the user POV (e.g. somehow
> disabling Gatekeeper, or Ctrl+Open, or something else) or from a
> developer POV (so, having to notarize)?
>
>
Instead of repeating myself here, please see my comment at
https://bugreports.qt.io/browse/QTBUG-73398?focusedCommentId=468111=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-468111
which
explains what I mean by "work around". I just added screen shots of the
dialogs I mentioned in that comment so it's clear what the user sees.


> I'd like to know if there is some reasonably simple way for users to
> get around the requirement. We will not be able to notarize every
> build we do, because of the time it takes. But at the same time we,
> and our testers, must be able to test random builds from Git (we build
> a .dmg for every commit) to try out in-progress features/bug fixes...
> So I really hope there will be some way for the user to get around the
> notarization requirement.
>

Notarization doesn't take more than a few minutes (in my limited
experience) but it's a hassle to script the process. Your build machines
and possibly your testers will not need to have a notarized application
because, as I understand it, notarization is not required if the
application does not have a quarantine flag. If it's been downloaded via a
standard web browser, it should have the flag. But if it was built on the
machine, or if it was transferred from another machine using something like
curl, rsync, etc. then it is unlikely to have the quarantine flag.

Of course, it is possible that in the future the quarantine flag will not
control whether the notarization check happens, so what I said in the
paragraph above may change.

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

Re: [Interest] Battery status and info

[Jérôme Godbout]

Hi,
Thanks for the info, how do you use the ideviceinfo? Can I monitor the battery 
with my iOS application with it? or is it run from desktop for an attached 
device?
I guess I would have to trigger the domain with the command:
ideviceinfo -d com.apple.mobile.battery

I need to monitor the host platform battery and charging progress within my 
application if possible.
I guess I will try to fetch all the information per platform, thanks for the 
info.


From: Jason H 
Sent: July 10, 2019 1:15 PM
To: Jérôme Godbout 
Cc: Interest@qt-project.org
Subject: Re: [Interest] Battery status and info

No. I had to write my own JNI api. Curiously, for iOS, the ideviceinfo binary 
can give you more than the device itself.

Sent: Wednesday, July 10, 2019 at 9:45 AM
From: "Jérôme Godbout" mailto:godbo...@amotus.ca>>
To: "Interest@qt-project.org" 
mailto:Interest@qt-project.org>>
Subject: [Interest] Battery status and info
Hi,
Is there any Qt API (I did found some into the old QtMobile) that can be used 
to probe the main battery on the system (I want to target iOS, Android, OS X, 
Window and Linux). I was wondering if any Qt API exist to monitor the charge 
level, the current, voltage, capacity, health, etc. I think I won’t get 
everything on all platform (yes I’m looking at you iOS lol). If anybody have a 
lead on this it would be welcome.

Thanks,
Jerome

___ 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] Battery status and info

[Jason H]

No. I had to write my own JNI api. Curiously, for iOS, the ideviceinfo binary can give you more than the device itself.
 

Sent: Wednesday, July 10, 2019 at 9:45 AM
From: "Jérôme Godbout" 
To: "Interest@qt-project.org" 
Subject: [Interest] Battery status and info




Hi,

Is there any Qt API (I did found some into the old QtMobile) that can be used to probe the main battery on the system (I want to target iOS, Android, OS X, Window and Linux). I was wondering if any Qt API exist to monitor the charge level, the current, voltage, capacity, health, etc. I think I won’t get everything on all platform (yes I’m looking at you iOS lol). If anybody have a lead on this it would be welcome.

 

Thanks,

Jerome

 

___ 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] notarizing builds for Mac - enabling hardened runtime

[coroberti .]

On Tue, Jul 9, 2019 at 8:56 PM Adam Light  wrote:

>
>
> On Fri, Jun 21, 2019 at 12:13 AM Kai Köhne  wrote:
>
>>
>> I understand that the "hardened runtime" enabling happens at codesign
>> time,
>> so this should arguably be a feature of macdeployqt. It's not there yet
>> though,
>> at least according to https://bugreports.qt.io/browse/QTBUG-71291 .  If
>> you're
>> right that this will become mandatory for macOS 10.15, it arguably get a
>> higher
>> priority; feel free to comment, including a link to the source of this
>> statement.
>>
>> For the time being, it seems you've to execute the codesign call yourself.
>>
>>
> Notarization is a requirement for macOS 10.15 (Catalina, currently in
> beta). See https://developer.apple.com/news/?id=06032019i for an official
> source of this requirement. In one of the WWDC 2019  talks about security
> and code signing/notarization, they mentioned that this was true for
> applications built (or maybe it's signed) after some date in early June.
> For example, Qt 4.9.2, released June 26, 2019, will not run on Catalina
> beta 3 without knowing how to work around the notarization requirement.
>
> Note also that notarization is separate from hardened runtime. An
> application built with the 10.14 SDK or later must enable hardened runtime
> in order for it to be possible to notarize the application, but it is
> possible to notarize applications built with previous SDK versions for
> which hardened runtime did not exist.
>
> See my comment at
> https://bugreports.qt.io/browse/QTBUG-73398?focusedCommentId=468111=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-468111
>  for
> some links that are particularly helpful in describing all of the
> complexities involved in notarization and hardened runtime.
>
> Adam
>
>
Adam,
Could you please provide more details about notarization without runtime
hardening by using SDK 10.13?
Specifically, which Xcode version was used and at which Mac OS?
Thanks,

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

Re: [Interest] qt creator 4.9.1 + qt 5.11.3 = android debugger not working

[Alexander Dyagilev]

why it's not possible to select qt creator version in online installer?

i have to install it separately and setup all qt versions and kits 
manually, which is very annoying.



On 7/10/2019 2:21 PM, Alexander Dyagilev wrote:


Installed 4.8.2 - debugger is working.

On 7/10/2019 1:01 PM, Alexander Dyagilev wrote:


4.8 worked fine for me. Until it has started to getting worse and 
worse with each new version. Until it got completely broken for me.



On 7/6/2019 11:52 PM, René Hansen wrote:

Might be related:

https://bugreports.qt.io/browse/QTCREATORBUG-20403

On Tue, 2 Jul 2019 at 21:51, Alexander Dyagilev > wrote:


Yes. I never build release versions on my machine.


On 7/2/2019 10:40 PM, Konstantin Tokarev wrote:
>
> 02.07.2019, 22:31, "Alexander Dyagilev" mailto:alervd...@gmail.com>>:
>> Hello,
>>
>> I've just noticed that debugger is not stopping on the
breakpoints. It
>> seems like it's not working at all.
>>
>> Is this a known problem? Do I have to upgrade to Qt 5.12 and
clang for
>> Android?
> Are you sure that you are using debug build?
>
___
Interest mailing list
Interest@qt-project.org 
https://lists.qt-project.org/listinfo/interest



--
Never fear, Linux is here.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Battery status and info

[Jérôme Godbout]

Hi,
Is there any Qt API (I did found some into the old QtMobile) that can be used 
to probe the main battery on the system (I want to target iOS, Android, OS X, 
Window and Linux). I was wondering if any Qt API exist to monitor the charge 
level, the current, voltage, capacity, health, etc. I think I won't get 
everything on all platform (yes I'm looking at you iOS lol). If anybody have a 
lead on this it would be welcome.

Thanks,
Jerome

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

[Interest] android: auto shutdown main process if is in background during some time

[Alexander Dyagilev]

Hello,

In my app I have 2 processes: activity with main UI (1st process) and a 
service (2nd one).


My activity takes (and updates) some data from service and displays it 
in its UI.


Service is not shutting down until activity is connected to it (I use 
QLocalServer in service).


So, the problem is that sometimes Android do not want to shutdown my 
acitity even if it's running for a long time in the background and the 
user is not using it. This leads to service running in the background 
too, and Android constantly warns the user about my app is running in 
the background.


Is there a way to automatically shutdown(kill) the activity if it's not 
active during some reasonable amount of time?


I've tried to use Activity.onPause and set timer, but main thread seems 
to paused and I just can't shutdown my app using the usual means of Qt.


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

Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[Elvis Stansvik]

Den ons 10 juli 2019 kl 13:20 skrev Andy :
>
> It sounds like not signing at all is still an option?

Yes, I guess not signing our builds (except releases), and asking
testers to use Ctrl-click + "Open" instead of double-clicking, is what
we'll do as a workaround, if it turns out there's no way for a user to
launch a signed build without it being notarized.

It's just a bit of awkward, I sort of liked how we had set up our CI
so that every build is essentially built like it was a release (well,
with the exception of this notarization, which we only do on tagged
releases due to the time it takes).

>
> "Mac apps, installer packages, and kernel extensions that are signed with 
> Developer ID must also be notarized by Apple in order to run on macOS 
> Catalina."
>
> Apple has made this way too complicated to be useful IMHO.

Yes, and it doesn't help that the notarization process is rather slow.
Oh well, one only has to accept it.

Elvis

>
> ---
> Andy Maloney  //  https://asmaloney.com
> twitter ~ @asmaloney
>
>
>
> On Wed, Jul 10, 2019 at 5:28 AM Elvis Stansvik  wrote:
>>
>> Den tis 9 juli 2019 kl 19:57 skrev Adam Light :
>> >
>> >
>> >
>> > On Fri, Jun 21, 2019 at 12:13 AM Kai Köhne  wrote:
>> >>
>> >>
>> >> I understand that the "hardened runtime" enabling happens at codesign 
>> >> time,
>> >> so this should arguably be a feature of macdeployqt. It's not there yet 
>> >> though,
>> >> at least according to https://bugreports.qt.io/browse/QTBUG-71291 .  If 
>> >> you're
>> >> right that this will become mandatory for macOS 10.15, it arguably get a 
>> >> higher
>> >> priority; feel free to comment, including a link to the source of this 
>> >> statement.
>> >>
>> >> For the time being, it seems you've to execute the codesign call yourself.
>> >>
>> >
>> > Notarization is a requirement for macOS 10.15 (Catalina, currently in 
>> > beta). See https://developer.apple.com/news/?id=06032019i for an official 
>> > source of this requirement. In one of the WWDC 2019  talks about security 
>> > and code signing/notarization, they mentioned that this was true for 
>> > applications built (or maybe it's signed) after some date in early June. 
>> > For example, Qt 4.9.2, released June 26, 2019, will not run on Catalina 
>> > beta 3 without knowing how to work around the notarization requirement.
>>
>> With "work around" do you mean from the user POV (e.g. somehow
>> disabling Gatekeeper, or Ctrl+Open, or something else) or from a
>> developer POV (so, having to notarize)?
>>
>> I'd like to know if there is some reasonably simple way for users to
>> get around the requirement. We will not be able to notarize every
>> build we do, because of the time it takes. But at the same time we,
>> and our testers, must be able to test random builds from Git (we build
>> a .dmg for every commit) to try out in-progress features/bug fixes...
>> So I really hope there will be some way for the user to get around the
>> notarization requirement.
>>
>> Elvis
>>
>> >
>> > Note also that notarization is separate from hardened runtime. An 
>> > application built with the 10.14 SDK or later must enable hardened runtime 
>> > in order for it to be possible to notarize the application, but it is 
>> > possible to notarize applications built with previous SDK versions for 
>> > which hardened runtime did not exist.
>> >
>> > See my comment at 
>> > https://bugreports.qt.io/browse/QTBUG-73398?focusedCommentId=468111=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-468111
>> >  for some links that are particularly helpful in describing all of the 
>> > complexities involved in notarization and hardened runtime.
>> >
>> > Adam
>> > ___
>> > 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] qt creator 4.9.1 + qt 5.11.3 = android debugger not working

[Alexander Dyagilev]

Installed 4.8.2 - debugger is working.

On 7/10/2019 1:01 PM, Alexander Dyagilev wrote:


4.8 worked fine for me. Until it has started to getting worse and 
worse with each new version. Until it got completely broken for me.



On 7/6/2019 11:52 PM, René Hansen wrote:

Might be related:

https://bugreports.qt.io/browse/QTCREATORBUG-20403

On Tue, 2 Jul 2019 at 21:51, Alexander Dyagilev > wrote:


Yes. I never build release versions on my machine.


On 7/2/2019 10:40 PM, Konstantin Tokarev wrote:
>
> 02.07.2019, 22:31, "Alexander Dyagilev" mailto:alervd...@gmail.com>>:
>> Hello,
>>
>> I've just noticed that debugger is not stopping on the
breakpoints. It
>> seems like it's not working at all.
>>
>> Is this a known problem? Do I have to upgrade to Qt 5.12 and
clang for
>> Android?
> Are you sure that you are using debug build?
>
___
Interest mailing list
Interest@qt-project.org 
https://lists.qt-project.org/listinfo/interest



--
Never fear, Linux is here.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[Andy]

It sounds like not signing at all is still an option?

"Mac apps, installer packages, and kernel extensions *that are signed with
Developer ID* must also be notarized by Apple in order to run on macOS
Catalina."

Apple has made this way too complicated to be useful IMHO.

---
Andy Maloney  //  https://asmaloney.com
twitter ~ @asmaloney 



On Wed, Jul 10, 2019 at 5:28 AM Elvis Stansvik  wrote:

> Den tis 9 juli 2019 kl 19:57 skrev Adam Light :
> >
> >
> >
> > On Fri, Jun 21, 2019 at 12:13 AM Kai Köhne  wrote:
> >>
> >>
> >> I understand that the "hardened runtime" enabling happens at codesign
> time,
> >> so this should arguably be a feature of macdeployqt. It's not there yet
> though,
> >> at least according to https://bugreports.qt.io/browse/QTBUG-71291 .
> If you're
> >> right that this will become mandatory for macOS 10.15, it arguably get
> a higher
> >> priority; feel free to comment, including a link to the source of this
> statement.
> >>
> >> For the time being, it seems you've to execute the codesign call
> yourself.
> >>
> >
> > Notarization is a requirement for macOS 10.15 (Catalina, currently in
> beta). See https://developer.apple.com/news/?id=06032019i for an official
> source of this requirement. In one of the WWDC 2019  talks about security
> and code signing/notarization, they mentioned that this was true for
> applications built (or maybe it's signed) after some date in early June.
> For example, Qt 4.9.2, released June 26, 2019, will not run on Catalina
> beta 3 without knowing how to work around the notarization requirement.
>
> With "work around" do you mean from the user POV (e.g. somehow
> disabling Gatekeeper, or Ctrl+Open, or something else) or from a
> developer POV (so, having to notarize)?
>
> I'd like to know if there is some reasonably simple way for users to
> get around the requirement. We will not be able to notarize every
> build we do, because of the time it takes. But at the same time we,
> and our testers, must be able to test random builds from Git (we build
> a .dmg for every commit) to try out in-progress features/bug fixes...
> So I really hope there will be some way for the user to get around the
> notarization requirement.
>
> Elvis
>
> >
> > Note also that notarization is separate from hardened runtime. An
> application built with the 10.14 SDK or later must enable hardened runtime
> in order for it to be possible to notarize the application, but it is
> possible to notarize applications built with previous SDK versions for
> which hardened runtime did not exist.
> >
> > See my comment at
> https://bugreports.qt.io/browse/QTBUG-73398?focusedCommentId=468111=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-468111
> for some links that are particularly helpful in describing all of the
> complexities involved in notarization and hardened runtime.
> >
> > Adam
> > ___
> > 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] qt creator 4.9.1 + qt 5.11.3 = android debugger not working

[Alexander Dyagilev]

4.8 worked fine for me. Until it has started to getting worse and worse 
with each new version. Until it got completely broken for me.



On 7/6/2019 11:52 PM, René Hansen wrote:

Might be related:

https://bugreports.qt.io/browse/QTCREATORBUG-20403

On Tue, 2 Jul 2019 at 21:51, Alexander Dyagilev > wrote:


Yes. I never build release versions on my machine.


On 7/2/2019 10:40 PM, Konstantin Tokarev wrote:
>
> 02.07.2019, 22:31, "Alexander Dyagilev" mailto:alervd...@gmail.com>>:
>> Hello,
>>
>> I've just noticed that debugger is not stopping on the
breakpoints. It
>> seems like it's not working at all.
>>
>> Is this a known problem? Do I have to upgrade to Qt 5.12 and
clang for
>> Android?
> Are you sure that you are using debug build?
>
___
Interest mailing list
Interest@qt-project.org 
https://lists.qt-project.org/listinfo/interest



--
Never fear, Linux is here.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[Elvis Stansvik]

Den tis 9 juli 2019 kl 19:57 skrev Adam Light :
>
>
>
> On Fri, Jun 21, 2019 at 12:13 AM Kai Köhne  wrote:
>>
>>
>> I understand that the "hardened runtime" enabling happens at codesign time,
>> so this should arguably be a feature of macdeployqt. It's not there yet 
>> though,
>> at least according to https://bugreports.qt.io/browse/QTBUG-71291 .  If 
>> you're
>> right that this will become mandatory for macOS 10.15, it arguably get a 
>> higher
>> priority; feel free to comment, including a link to the source of this 
>> statement.
>>
>> For the time being, it seems you've to execute the codesign call yourself.
>>
>
> Notarization is a requirement for macOS 10.15 (Catalina, currently in beta). 
> See https://developer.apple.com/news/?id=06032019i for an official source of 
> this requirement. In one of the WWDC 2019  talks about security and code 
> signing/notarization, they mentioned that this was true for applications 
> built (or maybe it's signed) after some date in early June. For example, Qt 
> 4.9.2, released June 26, 2019, will not run on Catalina beta 3 without 
> knowing how to work around the notarization requirement.

With "work around" do you mean from the user POV (e.g. somehow
disabling Gatekeeper, or Ctrl+Open, or something else) or from a
developer POV (so, having to notarize)?

I'd like to know if there is some reasonably simple way for users to
get around the requirement. We will not be able to notarize every
build we do, because of the time it takes. But at the same time we,
and our testers, must be able to test random builds from Git (we build
a .dmg for every commit) to try out in-progress features/bug fixes...
So I really hope there will be some way for the user to get around the
notarization requirement.

Elvis

>
> Note also that notarization is separate from hardened runtime. An application 
> built with the 10.14 SDK or later must enable hardened runtime in order for 
> it to be possible to notarize the application, but it is possible to notarize 
> applications built with previous SDK versions for which hardened runtime did 
> not exist.
>
> See my comment at 
> https://bugreports.qt.io/browse/QTBUG-73398?focusedCommentId=468111=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-468111
>  for some links that are particularly helpful in describing all of the 
> complexities involved in notarization and hardened runtime.
>
> Adam
> ___
> 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