Jump to content

xwiggen

Members
  • Posts

    136
  • Joined

  • Last visited

Posts posted by xwiggen

  1. https://apt.armbian.com/armbian.key

     

    if the image is signed by  Igor's key then it is an 'authentic' image. If signature verification fails due whatever reason (be it modification afterwards) the image is not authentic.

    The SHA hash only verifies the image but not who creates the SHA hash, for this you have signature verification.

     

    So, if either SHA, image or asc file are maliciously altered on server, you still have signature verification to verify it's an authentic image (which fail in case of modification, because it requires access to Igor's key to sign).

     

    The fingerprint we can read from the public key, but in the end we have no guarantee the pubkey is Igor's; for this ideally you'd like to check the fingerprint in person to verify the pubkey with a post-it.

    But it's not necessary really, at this point we can safely assume the key's Igor's and should it ever be compromised the key will be revoked.

     

    Read up on public key cryptography, the system is pretty locked down secure as it is.

  2. After you've imported the public key with step 1:

    % gpg --verify Armbian_20.08.1_Zeropi_bionic_current_5.8.5.img.xz.asc
    gpg: assuming signed data in 'Armbian_20.08.1_Zeropi_bionic_current_5.8.5.img.xz'
    gpg: Signature made Thu 03 Sep 2020 04:20:28 PM CEST
    gpg:                using RSA key DF00FAF1C577104B50BF1D0093D6889F9F0E78D5
    gpg: checking the trustdb
    gpg: no ultimately trusted keys found
    gpg: Good signature from "Igor Pecovnik <igor@armbian.com>" [unknown]
    gpg:                 aka "Igor Pecovnik (Ljubljana, Slovenia) <igor.pecovnik@gmail.com>" [unknown]
    gpg: WARNING: This key is not certified with a trusted signature!
    gpg:          There is no indication that the signature belongs to the owner.
    Primary key fingerprint: DF00 FAF1 C577 104B 50BF  1D00 93D6 889F 9F0E 78D5

    What it says is Armbian_20.08.1_Zeropi_bionic_current_5.8.5.img.xz is signed by Igor Pecovnik. If any bit is flipped in the xz after being signed (after download or modified on server) verification will fail.

     

    The only weakness in this is the public key  (as shown by WARNING above); you have to assume this is really Igor's pubkey and not compromised (but the keyserver's version and https://apt.armbian.com/apt/armbian.key match, the only thing more assuring would be if @Igor posts his fingerprint).

    You can trust this key as follows to remove the warning message;

    % gpg --edit-key 93D6889F9F0E78D5
    gpg (GnuPG) 2.2.12; Copyright (C) 2018 Free Software Foundation, Inc.
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    
    
    pub  rsa4096/93D6889F9F0E78D5
         created: 2015-03-16  expires: never       usage: SC
         trust: undefined     validity: unknown
    sub  rsa4096/9D465D88C70F53E4
         created: 2015-03-16  expires: never       usage: E
    [ unknown] (1). Igor Pecovnik <igor@armbian.com>
    [ unknown] (2)  Igor Pecovnik (Ljubljana, Slovenia) <igor.pecovnik@gmail.com>
    
    gpg> trust
    pub  rsa4096/93D6889F9F0E78D5
         created: 2015-03-16  expires: never       usage: SC
         trust: undefined     validity: unknown
    sub  rsa4096/9D465D88C70F53E4
         created: 2015-03-16  expires: never       usage: E
    [ unknown] (1). Igor Pecovnik <igor@armbian.com>
    [ unknown] (2)  Igor Pecovnik (Ljubljana, Slovenia) <igor.pecovnik@gmail.com>
    
    Please decide how far you trust this user to correctly verify other users' keys
    (by looking at passports, checking fingerprints from different sources, etc.)
    
      1 = I don't know or won't say
      2 = I do NOT trust
      3 = I trust marginally
      4 = I trust fully
      5 = I trust ultimately
      m = back to the main menu
    
    Your decision? 5
    Do you really want to set this key to ultimate trust? (y/N) y
    
    pub  rsa4096/93D6889F9F0E78D5
         created: 2015-03-16  expires: never       usage: SC
         trust: ultimate      validity: unknown
    sub  rsa4096/9D465D88C70F53E4
         created: 2015-03-16  expires: never       usage: E
    [ unknown] (1). Igor Pecovnik <igor@armbian.com>
    [ unknown] (2)  Igor Pecovnik (Ljubljana, Slovenia) <igor.pecovnik@gmail.com>
    Please note that the shown key validity is not necessarily correct
    unless you restart the program.
    
    gpg> save
    Key not changed so no update needed

     

    Hope this helps

  3. On 11/1/2020 at 8:01 PM, jeanrhum said:

    Looking at the documentation of jellyfin, only the rpi3 or 4 seems to be the supported boards based on an arm architecture.

     

    The  transcoding is handled by the jellyfin-ffmpeg package, which is basically a fork of ffmpeg. You can specify your own path to ffmpeg binary in settings, as the supplied binary is linked with raspberry libs (which is the only rpi specific code of jellyfin).

    Raspberry pi is ok for VPU.

     

    @Wernertry jellyfin on your NEO3 and compile ffmpeg with --enable-version3 --enable-rkmpp --enable-drm

     

    Personally I don't use transcoding but leave it all to the RPI3 (LibreElec) which happily plays all formats from SMB except for 10bit x265.

  4. 21 hours ago, busterrr3x said:

     

    Would you agree with this: "I have been told countless times that if malware were to write to my .img (file/image) while it sat in my download's folder, and then I ran the checksum, that the checksum would be inaccurate. " -----??

    Thanks. 

    It's not a checksum, it's a cryptographic hash (SHA). If you're able to change the image and keep the same hash, you've found a weakness in the SHA algorithm because it's not bruteforceable in our lifetime.

     

  5. On 10/31/2020 at 3:32 PM, MiCado said:
     

    Hi,

    i am using a tinkerboard s to run pihole, wireguard and a maria database. It worked quite a while without any issues. Just after I had to start over with the tinkerboard, the issues began.

     

    My main issue is, that after I restart the tinkerboard i do not get access right away to the internet. I have to open the pihole admin webpage first, just then I am able to get a normal internet connection.

    That works then without issues until another restart.

    I addressed my issue already in the pihole forum and the moderator suggested to ask here since in his opinion it might be an issue with the privacy extension of IPv6. I am honestly no expert and struggle quite a bit to get this issue fixed.

    Maybe somebody has an idea where I have to look and maybe can tell me which IPv6 addresses (fe80, fd00, ...) I have to use between pihole and my router to get it to work.

     

    thank you in advanced.

     

    I had similar issues with both dhcp clients enabled for ipv4 and ipv6 on the pihole, it's an issue with dhclient ipv6.

     

    My solution;

    Disable DHCP4/6 on the router and enable it on the pihole (SLAAC+RA,rapid commit), add static addresses for IPV6 and IPV4 (include router as gateway for both instances).

     

    in the router, set the dns4/dns6 settings to pihole and enable RFC5006 to allow for DNSv6 advertisement.

     

  6. 15 hours ago, KiwiChristian said:

    Ah, thank you. I have been trying to work out the problem.

     

    BUT, i never USED to have to do this.

     

    It is only in the last couple of months.

     

    I wasted money on a new orange pi and that does the same thing.

     

    One thing i have noticed, it says my sd card ( i assume where android is located ) is corrupt.

     

    I may try another sd card, but i only have a 4gb spare at the moment.

     

    Fake hwclock saves/restores the date on SD in Armbian between reboots, don't know about the specifics in Android.

     

  7. 6 hours ago, KiwiChristian said:

    I just wish i knew why i have to reset my date and time each time i power my orangepi on.

    This is because the realtime clock of the Pi is not battery-powered, i.e. after powercycle it resets to factory default. The ds1307/3231 do have battery but need i2c in kernel and additional configuration to be used as main RTC instead of the Pi RTC.

     

    In other words, by default the time is stored/restored on Pi RTC.

  8. On 10/19/2020 at 2:07 PM, jock said:

     Maybe the datasheets can make things a little clearer, but considering also that these SoCs are almost "ghosts" and they really look like production scraps I don't think I will find anything valuable there.

    Don't think so either,  considering reports about high load freezing on rk3288/rk3328 I suspect there's also some design issue wrt interrupt handling.

  9. 26 minutes ago, jock said:

    Do this happens only with mainline kernel or also with legacy kernel?

     

    Mainline only. Legacy runs stable at 73-81C, apart from GLES/GBM/FBDEV issues with mali blobs.

    Must say I've experienced some lockups with WiFi on H3 also with 5.8.x this week (RTL8189FS), one kernel panic on zeropi H3

  10. 17 hours ago, jock said:

    @xwiggen

     

     

    If your box works, I will remove that line in the generic setup (which is also useless there BTW, because it should be important only when DDR mode is in use).

    rk322x-box.dtb 39.87 kB · 2 downloads

    I flashed a 4.4 buster image to emmc, replaced the rk322x-box.dtb inside linux-dtb-current, removed linux-dtb-legacy/linux-image-legacy, installed linux-dtb-current/linux-image-current,

    and ...

    It works! :) Thanks very much. Will do some testing with GBM/GLES now

     

    edit: in 5.18 I see a mtd raw rockchip controller available? (not for me)

  11. 3 hours ago, jock said:

    Urgh, that's bad :unsure: dmesg should tell us something more, if you can upload it here it will be surely useful!

     

    Did you have your rootfs on eMMC or sdcard? I'd rather check on my boxes for the same behaviour, looks like something is missing/messing with device trees and mass storage device disappears.

     

    TBH, I never tried to upgrade from legacy to mainline via apt-get recently, so I hope there isn't a hole there. Stay tuned, I'll check ASAP.

     

    edit: don't you have NAND mass storage, do you? If so everything explains easily since NAND is not supported on mainline because there is no driver

     

    dmesg2__1602867206_80.127.236.83.jpg

    dmesg1__1602867181_80.127.236.83.jpg

  12. 2 hours ago, jock said:

    Well... it's pretty difficult to say if your board is borked or not, usually backpowering via USB is safe but manufacturers suggest to avoid.

    Anyway mali blobs have always had a bad reputation, and Mali400/450 drivers are terrible, so it is expected that you get an unresponsive system after some tries, it happened to me too, expecially if you are running thing in X11.

    NEON code should run pretty fine, didn't try by myself but I don't see a valid reason it should not. Also GBM consumers, like Kodi in fullscreen, should run better and be more stable than X11 applications.

     

    You may give a chance to mainline kernel with Lima, maybe compiling the latest debian which has very recent Mesa.

    Unfortunately later kernels (just tried rk322x 5.8.14 debs from apt.armbian, but also 5.x images) drop to initramfs, which I do not how to resolve;

    Loading, please wait....
    Starting version 241
    -etc-
    Begin: Running /scripts/local-block ... done
    -repeated ~20 times-
    done.
    Gave up waiting for root files system device. Common problems:
    -Boot args
    -check rootdelay
    -missing modules
    ALERT! UUID=.... does not exist Dropping to a shell!
    (initramfs)

    The UUID mentioned is correct.

     

  13. On 10/8/2020 at 7:28 AM, Werner said:

    True.

    I don't know much how this works but maybe sign the sha file against the authenticity key as well?

    There's no added security.

     

    If you're able to generate a SHA hash of the image and sign the SHA hash with the GPG-key both security measures are compromised at once, unless you want @Igor to sign every image and package manually at home.

     

  14. The locales package is required for locales anything other than C/POSIX, generation is necessary to be able to provide a lot smaller package rather than shipping all locales pregenerated -- i.e. did you install it?

     

    (/usr/bin/locale is libc stuff without actual locale data) 

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines