Anti rollback shoud have exceptions for when new software is bad/broken, you would be able to unlock/disable this feature (with some boot alerts or something).
It's not that bad that you might think, the db user just need to have readonly access permissions to specific database tables.
Ofc all data in tables ofc need to be public, so more like simple public facing page, app should not have any notion of users in any way, data probably populated by some automated system, and UI just to make it easier for anonymouse users to view that data in a friendly way.
On top of that it will be a hell for the sysops as they will need to know the whole db structure and such of even a single part of db would contain non-public data, but that overall the best guy to handle security in the first place.
And because all data is totally public in the first place you could give the task of creating frontend to any junior or LLM and it will be still secure.
But in truth it is very bad idea (even it it is possible), because most likely the database connections would be reused so you could for example change current connection session timezone or other params and that ofc would nit change the data in db but still could affect other users by showing wrongly formatted or shifted data.
True, you have a valid point, about outdated version of database running in background, as it does matter when you breach the prevuous layers.
My example was a little overreaching, because it sounded like you personally chosing to run old version is fine. Or like it doesnt matter at all. Which is not true. It just matter way way less in comparison of running old/exploitable part that is exposed directly to internet whout any protection.
In a sense if you gain code execution on the application then you can just read the database credentials and authorize yourself to gain full access to data as those applications dont have any database access rules applied, so having exploitable database or not dont change anything.
But if we are talking about high security levels with complex inner-connected services with many apps connecting/talking to database or exposing database outside as a mistake, then yes, totally agree with you.
I'm not saying that you should use old db, Im just saying that you dont need to knoe what db is used in a scenario where app and database is a pre-packaged bundle, because when you update you update whole package so you update both, you are not in controll of the database used and you dont even need to know, what you need to know and do is to Update the whole bundle ASAP.
In case of Nextcould, if you install it from snap/flatpak or use some bundled all-in-one container then you don't know what database is used and even if you know, then it could be hard to to do anything about it, as it is the package maintainer responsibility to update it.
But if its docker-conpose with 2 containers one for db, you are fully responsible, but then most likely you will know it is using mysql/postgres because it would be in your face.
Also you can use external services like Hetzner offers, then you know that you are using nextcloud but you dont know what they did decided to use as database backed, you are paying for service! So, its like asking if you knoe which database is used by your lemmy instance that you use.
Long story short: (As a user) if the database is bundled in app in a way it is not accessible from outside and is updated togheter with app or you are paying for it as a service, you as a user not knowing what database is running or even if it is using database at all doesnt matter. Just make sure its up-to-date.
What you are talking is about relates to the "unpatched applications" not about database running behind an app, as the difference does matter.
You can have 20years old database and it still be totally secure if the application (which is the guard in that scenario) correctly and very strictly sanitize its data.
So once again, it doesnt matter if I dont know what database is running inside some all-in-one app container, as long as this database is only accesed by the application and application is up-to-date and secure.
From every rules are exceptions, but it almost always boils down to the application not cirrectly sanetizing untrusted data.
It's some sorts of a bug, as it changes it size/offset if you interact with it in some ways.
Has that multiple times but didn't know how to reproduce it or if its not even only on my phone (fairphone 5)
Not really, they might not know because it is a hosted service like from Hetzner or they did start some prebuild (for example docker-compose) package and most of those have database attached locally without exposing it outside.
Fake news, CEO and all emplyes are getting pay'd in full, it doesn't matter if they sell the product to its users or sell (user data) to their sponsors or share the data internaly, it doesnt matter that the service model itself is not profitable as they make the rest from selling a (fake?) promises.
Same with many others like Youtube, they are also "not profitable" on paper as a standalone service. It only mean they are using you, selling your data or selling some promises.
If they would actully not be profitable then they would rise prices or just disapear and some other company would arise but with srtategy that is at least sustainable.
Open source devs can be losing money, as the pay from their own pockets.
I would like to see at least one person in that company that is not getting money from it but fund it from own money.
I dont have an issue with a feature to allow my phone to automatically veirfy signatures. But there should be a way to import/configure more signature verification providers including my own authority and even then it should still allow imstall if user really want and trust it.
And then Motorola hijack your URs that your open on your phone and adding their something to the URL for profit....
Anti rollback shoud have exceptions for when new software is bad/broken, you would be able to unlock/disable this feature (with some boot alerts or something).
Grayjay
It's not that bad that you might think, the db user just need to have readonly access permissions to specific database tables.
Ofc all data in tables ofc need to be public, so more like simple public facing page, app should not have any notion of users in any way, data probably populated by some automated system, and UI just to make it easier for anonymouse users to view that data in a friendly way.
On top of that it will be a hell for the sysops as they will need to know the whole db structure and such of even a single part of db would contain non-public data, but that overall the best guy to handle security in the first place.
And because all data is totally public in the first place you could give the task of creating frontend to any junior or LLM and it will be still secure.
But in truth it is very bad idea (even it it is possible), because most likely the database connections would be reused so you could for example change current connection session timezone or other params and that ofc would nit change the data in db but still could affect other users by showing wrongly formatted or shifted data.
Good to know that it's not every friday but specific days of year. So today and next one is in december.
Sorry, didn't read other comments, so it is already known bug :)
Found the cause for my observed issue, if you grab the timeline by the text box then the text is moved inside the box.
Recording: https://nextcloud.dlk.pl/s/qfzCXsGXXPHq5mD
True, you have a valid point, about outdated version of database running in background, as it does matter when you breach the prevuous layers.
My example was a little overreaching, because it sounded like you personally chosing to run old version is fine. Or like it doesnt matter at all. Which is not true. It just matter way way less in comparison of running old/exploitable part that is exposed directly to internet whout any protection.
In a sense if you gain code execution on the application then you can just read the database credentials and authorize yourself to gain full access to data as those applications dont have any database access rules applied, so having exploitable database or not dont change anything.
But if we are talking about high security levels with complex inner-connected services with many apps connecting/talking to database or exposing database outside as a mistake, then yes, totally agree with you.
I'm not saying that you should use old db, Im just saying that you dont need to knoe what db is used in a scenario where app and database is a pre-packaged bundle, because when you update you update whole package so you update both, you are not in controll of the database used and you dont even need to know, what you need to know and do is to Update the whole bundle ASAP.
In case of Nextcould, if you install it from snap/flatpak or use some bundled all-in-one container then you don't know what database is used and even if you know, then it could be hard to to do anything about it, as it is the package maintainer responsibility to update it.
But if its docker-conpose with 2 containers one for db, you are fully responsible, but then most likely you will know it is using mysql/postgres because it would be in your face.
Also you can use external services like Hetzner offers, then you know that you are using nextcloud but you dont know what they did decided to use as database backed, you are paying for service! So, its like asking if you knoe which database is used by your lemmy instance that you use.
Long story short: (As a user) if the database is bundled in app in a way it is not accessible from outside and is updated togheter with app or you are paying for it as a service, you as a user not knowing what database is running or even if it is using database at all doesnt matter. Just make sure its up-to-date.
Text size dorsnt change, the viewport gets bigger and the text get shifted to a correct position like fixing itself.
But i only saw that like handfull of times.
If you can feed the database malicious data and commands then you are dirrectly connected to it or application is not correctly sanetizing the data.
What you are talking is about relates to the "unpatched applications" not about database running behind an app, as the difference does matter.
You can have 20years old database and it still be totally secure if the application (which is the guard in that scenario) correctly and very strictly sanitize its data.
So once again, it doesnt matter if I dont know what database is running inside some all-in-one app container, as long as this database is only accesed by the application and application is up-to-date and secure.
From every rules are exceptions, but it almost always boils down to the application not cirrectly sanetizing untrusted data.
It's some sorts of a bug, as it changes it size/offset if you interact with it in some ways. Has that multiple times but didn't know how to reproduce it or if its not even only on my phone (fairphone 5)
Not really, they might not know because it is a hosted service like from Hetzner or they did start some prebuild (for example docker-compose) package and most of those have database attached locally without exposing it outside.
It have a very small amount of informations about it.
Would be nice to have some details about:
Only android and Desktop. But it's a good start.
Fake news, CEO and all emplyes are getting pay'd in full, it doesn't matter if they sell the product to its users or sell (user data) to their sponsors or share the data internaly, it doesnt matter that the service model itself is not profitable as they make the rest from selling a (fake?) promises.
Same with many others like Youtube, they are also "not profitable" on paper as a standalone service. It only mean they are using you, selling your data or selling some promises.
If they would actully not be profitable then they would rise prices or just disapear and some other company would arise but with srtategy that is at least sustainable.
Open source devs can be losing money, as the pay from their own pockets.
I would like to see at least one person in that company that is not getting money from it but fund it from own money.
They try to push Chat Control every year for some time now...
I dont have an issue with a feature to allow my phone to automatically veirfy signatures. But there should be a way to import/configure more signature verification providers including my own authority and even then it should still allow imstall if user really want and trust it.