Dietpi: Info : In response to mayan-edms.com

[Fourdee]

https://twitter.com/MayanEDMS/status/1015807347380416512

We take security very seriously at DietPi:

If any claims can be made (that contain proof, and, factual information to back it up), we will investigate it and resolve with the highest priority.

However, the only reasons I can find for this person to make this claim, is based on two comments on the post, with no valid proof or factual information to back them up ("here-say").

Comment 1:

In regards to LSB:

• As of DietPi v6.9, users are now prompted to change their linux passwords on the system. During 1st run, or during the update patch.
• We do have some remaining software installations (through dietpi-software), which run under root. We are working on this to ensure they run as their own user (https://github.com/Fourdee/DietPi/issues/1877).
  Regardless, the only situation in which this could be a security concern, is if the software title (eg: nextcloud), was to purposely add miscellaneous code into their project. In which case, we would make the public aware of this, and drop nextcloud from our software database.

In regards to collected data:

• Users are prompted to OPT IN or OUT. The anonymous data we collect can be viewed here: https://dietpi.com/survey/.
• If you OPT OUT, the contents of your survey file is wiped from our servers, and contains no information.
• This information is used only to improve DietPi, based on the popularity of installed software and chosen hardware.
• The exact content of the uploaded file is shown on OPT IN/OUT prompt (see below)
  

Comment 2:

In regards to the mentioned devices

• We do not support the devices mentioned, or, provide any official images for them.
• Previously, we did provide images and support for these devices, which ran on ARMbian. However, due to various reasons (including instability with ARMbian), we dropped those devices and images.

In regards to overwriting config files during updates

• Yes we do, however, not blindly and only when no other viable option is possible. We patch the system as required, to ensure system, DietPi programs (and software installed with them) work as intended.
• DietPi is different, in that its designed for the user to use the available DietPi programs, which replaces the need, for manual editing of linux files.

In regards to inability to audit changes

• With significant patch changes, we provide a prompt for the user to inform them of the changes during patching.
• Our patches which may change configuration files, only target installed software through DietPi and core system items which DietPi relies on to function.
• DietPi is completely open-source, the patch code/changes can always be viewed here: https://github.com/Fourdee/DietPi/blob/master/dietpi/patch_file

[MichaIng]

@Fourdee
Not very fact based, more emotional Trump like argumentation, otherwise just very bad journalism, mentioning exactly the points that we just took care about (as you mention very well above).

It is a quite common issue, that if you take care security and privacy concerns and make things more transparent, inform users etc., the impression is "Huh, data is collected?" "Huh, I should have changed my password?" a negative impression, instead of a positive one, that things gotten in fact more transparent and secure. But someone, who writes and shares "official" recommendations should be expected to have a deeper look.

Perhaps add to In regards to collected data: as second bullet:

• The exact content of the uploaded file is shown on OPT IN/OUT prompt (see below)

[MichaIng]

If only they put these efforts into own their project. With a focused effort, it could be more successful and stable than DietPi.

Indeed, larger dev team, although kernel development included, but they do not have to take care all the software offer related parts, which break our stability by times, if a new different behaving update with different dependencies e.g. appears.

It is a shame, actually ARMbian and DietPi could enhance each other very greatly like backend / frontend. With some nice communication, clear differentiation of each others work and readdressing bug reports accordingly in case, both sides would greatly benefit. But yeah, other topic...

[Fourdee]

Marking as closed.