Add Date and Time.app

[Hierosme]

Fix for #165

[probonopd]

Thanks @Hierosme. Getting this error:

Can we ship a private copy of this file? Or do we need to install some package in the system?

[probonopd]

I have cleaned up the Markdown in Resources/docs/README.md a bit, but it is pointing to non-existing images. Either we should remove those links, or we need to add the images.

Note to self: When this gets merged, the Markdown needs to go to https://hellosystem.github.io/docs/

[Hierosme]

Thanks @Hierosme. Getting this error:

Can we ship a private copy of this file? Or do we need to install some package in the system?

Here that my bad, i need more time for make it work.

i have to code wrapper for take the Environement Variable $TZ with precedence of "/etc/timezone" and permit the case where both is not present.

The "etc/timezone" is the default file of ntpd, because ntpdaate is consider deprecated by FreeBSD and will be not aviable on next major.

Yes helloSytem should consider to migrate to ntpd , the Fronted target a /etc/ntpd.conf and /etc/timezone or $TZ.

The TZ env var is a good way to have TimeZone with a live CD.

[Hierosme]

I have cleaned up the Markdown in Resources/docs/README.md a bit, but it is pointing to non-existing images. Either we should remove those links, or we need to add the images.

Note to self: When this gets merged, the Markdown needs to go to https://hellosystem.github.io/docs/

About Documentation,

That is worng mannipulation, due to the split of the original pull request, screenshoot is not here because i waiting for finished product before take any screenshoot.

What you have inside the README is my documentation plan , the publication of that file is a error.

[probonopd]

Yes helloSytem should consider to migrate to ntpd

Can you help me with that?

[Hierosme]

Yes helloSytem should consider to migrate to ntpd

Can you help me with that?

Certainly, i'll not let you like that, and the Date and Time.app have it step as requirement.

[probonopd]

Let's open a new issue for the migration in https://github.com/helloSystem/ISO.

[Hierosme]

Let's open a new issue for the migration in https://github.com/helloSystem/ISO.

Let have fun !

https://github.com/helloSystem/ISO/issues/511

[Hierosme]

@probonopd It look impossible to use systemTrayIcon class for write digital clock.

It have many cause: The systemTray is suppose to be resize into square ratio only The systenTray can only display a Icon QIcon cant display text, it must be a repaint then have the Text as picture FreeDesktop have simply omit text only capability, icon cant be UTF-8 symbole What have been done by Qt lib on SystemTray is a ULTRA limited class.

Brief it have no way to display Text or only with a very bad workarround it consist to create one systemtrayIcon object by letter. (That is clear not acceptable)

A good way is to use the Filer.app (Global Menu) Clock, and use a plain text configuration file. Same result can normally be obtain over DBUS, where Date and Time.app send setting to the Global Menu Clock Widget over a Bus.

In summary the systemTrayIcon from Qt is really a bad, and not permit to create widget like, Battery percentage, CPU Percentage, Digital clock. Each time that a workarround because the Qt have make bad job on it class. I dont know how to.

[probonopd]

I don't understand what you want to change regarding systemTray, but I am happy with how it is:

This is by the way part of https://github.com/helloSystem/Menu and has nothing to do with this repository (Utilities) or this pull request (#188).

[Hierosme]

Yes i speacking about The DateTime of Menu.app

The plugin is a True widget.

class DateTimeWidget : public QWidget

and it have no way to inform that widget about the date string format, then by exemple match with the setting of Date and Time.app

My first approch was to think about provide the digital clock with Date and time.app , but QSystemtrayIcon simply cant act like a widget.

I have look the source code on Menu Datetime plugin, https://github.com/helloSystem/Menu/tree/main/plugin-datetime but it havent any percitent setting, or DBus connection.

Then that is impossible to have any type of user preferences.

Do i delete the Tab about Digital clock setting ?

[Hierosme]

By the Way:

We can respect the POSIX about date string format where for date CLI use TZ and LC_TIME env var: https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/ https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html#tag_07_03_05

The percistence can be obtein by just write in /etc/profile

That is a good option for live CD, but the actual Menu.app dont have entry point for change date string format.

[probonopd]

Menu.app uses the format defined by the system via environment variables. E.g., when you set the language to German you get different formatting (e.g., no AM/PM) than if you set it to US English. So it is already working "automagically" (Qt handles it for us).

So, we do not need (and don't support) the tab "Clock" in "Date and Time".

Please let me know once you think this PR is ready for merging. Let's not overengineer it ;-)

[Hierosme]

Let's not overengineer it ;-)

LOL Exactlly what i just asking to me when i have re-read my code it detect value of TimeZone:

    @pyqtProperty(str)
    def TimeZone(self):
        return self.__timezone

    @TimeZone.setter
    def TimeZone(self, value):
        if value is None:
            info1 = QFileInfo(self.__timezone_default_path)
            if os.getenv("TZ"):
                value = os.environ.get("TZ")
            elif info1.exists() and (info1.isFile() or info1.isSymLink()):
                if info1.isSymLink():
                    info1 = QFileInfo(info1.symLinkTarget())
                if info1.isFile() and info1.isReadable():
                    try:
                        file_handle = QFile(info1.absoluteFilePath())
                        file_handle.open(QFile.ReadOnly)
                        data = file_handle.readAll()
                        codec = QTextCodec.codecForUtfText(data)
                        value = codec.toUnicode(data).strip("\n")

                    except (Exception, BaseException):
                        raise IOError("Problem reading file %s" % info1.absoluteFilePath())

        if self.__timezone != value:
            self.__timezone = value
            self.TimeZoneChanged.emit()

Please let me know once you think this PR is ready for merging.

I still have work to do but i'll resume it to reach soon a frist testable version

[Hierosme]

In fact everything is finish except the security arround sudo usage. I cant fixe without any design.

I'll pass it PR as Ready for Review soon, but i'll let comment the sudo usage part. Someone (Not me) will have to enable the security hole by him self.

The GUI hard work have been done, now it just require a permission escallation Backend.

Without it Permission escalation backend that will be the last preference tool i touch. When i have start to touch it i have never imagine helloSystem havent any permission escalation design. That take a tone of time to make it work and the final result is a True security hole, it have been a ultra bad expereience to me.

I havent any security hole to merge on the main branch .... Who understand the goal of havent a permission escalation design ?

[probonopd]

Using helper applications with sudo is how things are done in helloSystem. For example, if your application needs to invoke a command line tool to change the time, then it needs to invoke that command line tool with sudo. Upon invocation, the user will be asked to enter the root password. If the user doesn't have that password and presses cancel, then the operation will not be performed. Simple!

[Hierosme]

Frist i,m sorry, because my english skill is limited for explain how is my furstration about it. I m limited for stay cool, with true explainations.

Second.

We have all ready speack about, that a big NO from my part, Sudo should be use TOP to Down and not Down to Top. setuid work like that ....

The usage of sudo inside helloSystem is worng, that is write many timewrite inside sudo manual, the env var heritage is sommething hard to secure.

Security is more complicated, if it was so simple everyone will use sudo.

From Dev point of view: The responssability should be send to a backend (here sudo), the application should not care about sudo.

Arctuallyt he only way to secure the "Date and Time.app" i have make is to start them with sudo. like: sudo /Utilities/Date.app/Ressources/date_time.py

life is like that, my skill not permit both security couple with nice GUI. May be after fews hiteration we found a secure way.

Here i can only limited the impact of a worng usage of sudo.

Apologize again if my english look rude, that clealy because i'm limited for explain me.

Regards

[probonopd]

Hi @Hierosme, I appreciate your constructive dialog. Maybe I am having a hard time understanding your points due to the language barrier. To me, frameworks like polkit are insecure by design because they are complex and most people don't understand what is going on. When calling something with sudo, most people do know what is going on: "you are running this as root".

Now, for a GUI application, there are 2 possible ways:

• Running the whole GUI application as root. Some people think that this is a bad idea, because this way the whole thing runs as root
• Running the GUI application not as root but as a normal user, and have it call helper (CLI) tools which are run as root with sudo. This is usually the better way, isn't it?

Can you elaborate how/why this would be less secure than using a more complicated system?

Sudo should be use TOP to Down and not Down to Top. setuid work like that ....

What do you mean by this? Can you give an example? I am really trying to understand your point.

Feel free to answer in your native language if it is easier for you. I will find a way to translate. Thanks!

[Hierosme]

Hi @Hierosme, I appreciate your constructive dialog. Maybe I am having a hard time understanding your points due to the language barrier. To me, frameworks like polkit are insecure by design because they are complex and most people don't understand what is going on. When calling something with sudo, most people do know what is going on: "you are running this as root".

Now, for a GUI application, there are 2 possible ways:

• Running the whole GUI application as root. Some people think that this is a bad idea, because this way the whole thing runs as root
• Running the GUI application not as root but as a normal user, and have it call helper (CLI) tools which are run as root with sudo. This is usually the better way, isn't it?

Can you elaborate how/why this would be less secure than using a more complicated system?

Sudo should be use TOP to Down and not Down to Top. setuid work like that ....

What do you mean by this? Can you give an example? I am really trying to understand your point.

Feel free to answer in your native language if it is easier for you. I will find a way to translate. Thanks!

Sorry for the delay i was in travel for my job...

I'm back and tak a moment for response. No warry You are the man about helloSystem i have to follow, look clear for me.

From my point i know how it should do, but that just my point, if consider helloSystem my point is just a point like other one.

Thanks to trust my motivation.

Actually i'm busy with a CI/CD migration for a other project, but i come soon (from now i'm near, next travel i few mouths)

last time i have rush on Grab.app it still have work but i'll switch back to the sudo trouble. Normally the code is OK everthing is finish, it just have sudo to enable....

regards cher...