W dniu 2024-05-31 o 23:44, io pisze:

> Ktoś, nie ja.

Ok. Nie zauważyłem.
Nie będę teraz przeglądał historii.
Myślałem, że jak na opis, że 'się wgrało' zareagowałem hasłem, że to
musiał być kiepski programista to odpowiedziała mi ta sama osoba co
zapodała, że 'się wgrało'.

>> A skutecznym sposobem zabezpieczenia jest podpisywanie pliku będącego
>> wsadem.
>
> Raczej sprawdzanie tego podpisu.

:)
O oczywistych oczywistościach zwykłem nie pisać.
Początkiem była informacja, że drukarka łyknęła jakiś losowy plik jako
swój nowy wsad.
Napisałem, że powinien być podpisywany a w domyśle, że oczywiście po to,
aby sprawdzić ten podpis przed zaakceptowaniem pliku jako nową wersję softu.

>> Jak się dowiedziałem, że mowa o open hardware to stwierdziłem, że
>> zabezpieczenie może być dużo słabsze,
>
> Bo?

Ktoś, kto sobie poskładał coś open hardware może z tym robić co chce.
W przypadku produktu za którego działanie bierze odpowiedzialność jego
producent nie powinno być łatwej metody 'zepsucia go' i wysłania do
naprawy gwarancyjnej.

>> ale jeśli ktoś go w ogóle nie przewidział i łyka jako nową wersję
>> jakikolwiek plik to nadal nie mam dobrego zdania o jego wyobraźni.
>
> Nie tak działają zwykłe programatory? No ale trzeba się podłączyć
> fizycznie. Tam, gdzie podłączać się nie trzeba wprowadza się adekwatne
> zabezpieczenia. Ale to przecież nie po to, by odebrać użytkownikowi
> możliwość programowania urządzenia, którego jest właścicielem. Chyba, że
> tego właśnie chce, np systemy safety.

Oprogramowanie to taka sama część urządzenia jak każdy inny fragment
jego budowy. Każda ingerencja według mnie powoduje, że od teraz
producent już nie powinien odpowiadać za naruszenie przez urządzenie
jakichś przepisów (np. dotyczących bezpieczeństwa, ale nie tylko).
Ingerencja w budowę mechaniczną jest zazwyczaj łatwa do stwierdzenia
nawet jak to urządzenie było źródłem pożaru. Sprawdzenie w takim
przypadku, że był podmieniony software jest znacznie trudniejsze więc
lepiej jest po prostu to uniemożliwić.

>>>>> No i widzisz, jak się zmieniło WiFi z 'a' na 'g' to niektóre
>>>>> urządzenia dało się zaktualizować a niektóre nie.
>>>>
>>>> Nie znam się na WiFi. Jesteś pewien, że to tylko złośliwość
>>>> producenta a nie brak niezbędnych możliwości sprzętowych.
>>>
>>> Nikomu nie wmawiałem złośliwości. Po prostu finalnie jeden produkt po
>>> wymianie karty wspierał nowy standard a drugi nie wspierał bo np w
>>> trosce o rzekome bezpieczeństwo zrealizowano interfejs WiFi tak, by
>>> nie dało się go podmienić.
>>
>> W przenośnym czytniku RFID zastosowaliśmy dostępny na rynku moduł
>> ZigBee, który wydał się nam najrozsądniejszy.
>> W module tym jest mikroprocesor, który poza załatwieniem ZigBee może
>> też obsługiwać jakiś sprzęt na zewnątrz to zrobiliśmy z niego
>> sterownik całego naszego urządzenia. Tak wychodzi taniej więc cena
>> może być mniejsza.
>>
>> Taka po prostu koncepcja projektu.
>>
>> Teraz załóżmy, że zmienia się ZigBee z 'a' na 'g'.
>> Uważasz, że lepiej było:
>> - dać osobny procesor załatwiający to co robi nasze urządzenie tak aby
>> moduł można było zawsze po prostu wymienić,
>> - zamiast wlutowywać moduł (moduł wklejamy i lutujemy drucikami, bo
>> produkcja kilku sztuk rocznie więc ręcznie, a moduł ma pady ukryte pod
>> spodem płytki (do lutowania w piecu)) przewidzieć jakieś złącze dla
>> niego,
>> - sam moduł zmontować na jakiejś płytce ze złączem pasującym do tego
>> na płycie głównej,
>> - wybrać większą obudowę, aby ta konstrukcja się zmieściła,
>> - wgrywać na produkcji dwa wsady - osobno do modułu i osobno na główną
>> płytę,
>> - mieć ewentualny problem z rozłączeniem się zlącza, gdy komuś zdarzy
>> się upuścić czytnik.
>>
>> Serio uważasz, że tak właśnie powinniśmy zrobić tylko po to, że jak
>> się pojawi ZigBee 'g' to użytkownik będzie mógł sobie:
>> - kupić moduł obsługujący 'g',
>> - zrobić płytkę na którą go nalutuje,
>> - zastąpić tą płytką tę dotychczasową,
>> - napisać sobie programy dla modułu i płyty głównej.
>
> Nie wystarczy wgrać program do nowej płyty?

Ja tylko tłumaczę, że czasami hardware z takich, czy innych (zazwyczaj
racjonalnych) powodów został tak zrobiony, że jak ktoś zmienił Wifi z
'a' na 'g' to może nie być możliwości dopasowania się do 'g' poprzez
jedynie wgranie programu.
A tłumaczę, bo napisałeś, że niektórzy umożliwiali, a inni nie.

> Ja tylko o tym, że producent nie ma powodu odbierać użytkownikowi
> możliwości programowania urządzenia, którego jest właścicielem.

Oczywiście, że ma powód. Chodzi o jego odpowiedzialność za produkt.
Prawo jest coraz bardziej takie, że jak jakiś idiota się poparzy bo
wymyśli, żeby wyprasować koszulkę na sobie to się okaże, że winny jest
producent, bo mógł to przewidzieć, a nie przewidział i nie napisał
odpowiedniego ostrzeżenia w instrukcji.

Jak wyrób ma oprogramowanie to na pewno jest to wyrób elektroniczny.
Podlega więc pod EMC, RoHS, WEEE. Jeśli jest jakoś połączony do sieci AC
to podlega też pod LVD. Jeśli ma jakąś komunikację bezprzewodową to
podlega też pod RED. Zależnie od konkretnego typu wyrobu, może też mieć
obowiązek bycia w zgodzie z jakąś normą.
Producent odpowiada za spełnienie wszystkich wymogów wymienionych przeze
mnie dyrektyw, a może i innych o których nie słyszałem.
W spełnieniu niektórych wymogów niektórych dyrektyw istotną rolę odgrywa
oprogramowanie. Od razu kojarzą się EMC, RED, ale w przypadku LVD też
można sobie wyobrazić wpływ softu na spełnienie jej wymagań.

Nawet potencjalna możliwość, że gdzieś u kogoś zostanie ujawniony
produkt danego producenta nie spełniający wymogów jest według mnie
wystarczającym powodem aby uniemożliwiać użytkownikowi modyfikację
oprogramowania.

>> Aby można było sobie wgrywać co się chce to zapewne musiałby być jakiś
>> standardowy system operacyjny. > Czyli coś, nad czym w moim pojęciu
>> się nie panuje (jestem elektronikiem,
>> nie informatykiem).
>
> Przecież dostajesz moduły, które można swobodnie programować bez systemu
> operacyjnego.

Nie do końca rozumiem co masz na myśli.
Mam wrażenie, że piszesz o jakichś modułach, które są dopiero
półproduktami, a ja piszę o końcowych wyrobach trafiających do użytkwonika.

> Nie bardzo rozumiem o jakim systemie piszesz. Może coś więcej napisz, bo
> nie rozumiem o co chodzi.

System kontroli dostępu to coś, co wpuszcza tylko osoby uprawnione
(karta, pin, odcisk palca, kształt dłoni i co tam jeszcze wymyślą).
Gdy rozproszony po kraju (wiele oddziałów firmy, zakładów, czy
jednostek) to naturalne do niezbędnej wymiany informacji jest
wykorzystanie internetu.
No i jeśli założyć, że w takim systemie użytkownik powinien mieć
możliwość dogrywania jakichś swoich modułów (tak zrozumiałem opisane
przez Ciebie oczekiwania) to chyba jedyną możliwością byłoby oparcie
tego na jakimś ogólnodostępnym systemie (typu LINUX). W każdym tego typu
systemie odkrywane są co jakiś czas jakieś luki i wymagane jest wgranie
jakichś łatek.
Tylko, że audyt bezpieczeństwa systemu był wykonany dla konkretnego
oprogramowania (jak to był system z możliwością dogrywania modułów
użytkownika to wyobrażam sobie, że audyt badający, że dowolny dograny
moduł nie naruszy bezpieczeństwa zasadniczego oprogramowania musiałby
być .... kosztowny).

Ogólnie uniemożliwienie modyfikacji programu przez użytkownika i
uniemożliwienie mu dogrywania jakichkolwiek jego własnych kawałków
uważam, za jedynie słuszne rozwiązanie.

>> Ja uważam, że z modelu z możliwością wgrywania co się chce właśnie by
>> nic dobrego nie wynikło.
>
> Już samo to, że z tego dokładnie korzystasz, wynika, że już 'coś dobrego
> wyniknęło'.

Rozumiem, że piszesz o tym, że korzystam z komputera na którym mam
wgrany jakiś program pocztowy.

Oczywiście komputer bez możliwości wgrywania i uruchamiania na nim
programów użytwkownika nie ma sensu.
Ale według mnie z kolei system kontroli dostępu z możliwością dogrywania
na nim i uruchamiania oprogramowania użytkownika też nie ma sensu bo
wymagało by to zbyt kosztownych działań niezbędnych do zapewnienia
zachowania bezpieczeństwa systemu i niepogorszonej jego funkcjonalności
bez względu na zawartość wgranej aplikacji użytkownika.
P.G.