Recherche avancée

Sur d’autres sites (6979)

• How to verify signatures for Piwik release packages

  19 novembre 2014, par Piwik Core Team — Security

  We are proud to announce that Piwik project now cryptographically signs the Piwik releases using PGP following requests from several community members. In this post we will explain how you can verify the signatures of the Piwik release you downloaded, with instructions for Windows, Mac OS X and Linux.

  What is a signature and why should I check it ?

  ---

  How do you know that the Piwik platform you have is really the one we made ? Some software sites list sha1 hashes alongside the software on their website, so users can verify that they downloaded the file without any errors. These “checksums” help you answer the question “Did I download this file correctly from whoever sent it to me ?” They do a good job at making sure you didn’t have any random errors in your download, but they don’t help you figure out whether you were downloading it from a compromised server. The better question to answer is : “Is this file that I just downloaded the file that Piwik intended me to get ?”. Over the years several Piwik users have requested that we start signing our releases.

  Where do I get the signatures and the keys that made them ?

  ---

  Each file on our release server builds.piwik.org is accompanied by a file with the same name as the package and the extension .asc. These .asc files are GPG signatures. They allow you to verify the file you’ve downloaded is exactly the one that we intended you to get. For example, piwik-2.9.0.zip is accompanied by piwik-2.9.0.zip.asc<code>.

  Currently Matthieu Aubry is the release manager and signs the Piwik releases. His signature can be found here : builds.piwik.org/signature.asc

  How to verify signatures on Windows

  ---

  You need to have GnuPG installed before you can verify signatures. Download it from http://gpg4win.org/download.html.

  Once it’s installed, use GnuPG to import the key that signed your package. Since GnuPG for Windows is a command-line tool, you will need to use cmd.exe. Unless you edit your PATH environment variable, you will need to tell Windows the full path to the GnuPG program. If you installed GnuPG with the default values, the path should be something like this : C :\Program Files\Gnu\GnuPg\gpg.exe.

  Import Piwik Release manager Matthieu’s key (0x416F061063FEE659) by starting cmd.exe and typing :

  "C :\Program Files\Gnu\GnuPg\gpg.exe" —keyserver keys.gnupg.net —recv-keys 814E346FA01A20DBB04B6807B5DBD5925590A237

  After importing the key, you can verify that the fingerprint is correct :

  "C :\Program Files\Gnu\GnuPg\gpg.exe" —fingerprint 814E346FA01A20DBB04B6807B5DBD5925590A237

  You should see :

  pub   4096R/5590A237 2013-07-24
        Key fingerprint = 814E 346F A01A 20DB B04B  6807 B5DB D592 5590 A237
  uid                  Matthieu Aubry <matt@piwik.org>
  uid                  Matthieu Aubry <matthieu.aubry@gmail.com>
  uid                  Matthieu Aubry <matt@piwik.pro>
  sub   4096R/43F0D330 2013-07-24
  

  To verify the signature of the package you downloaded, you will need to download the ".asc" file as well. Assuming you downloaded the package and its signature to your Desktop, run :

  "C :\Program Files\Gnu\GnuPg\gpg.exe" —verify C :\Users\Alice\Desktop\piwik-2.9.0.zip.asc C :\Users\Alice\Desktop\piwik-2.9.0.zip

  The output should say "Good signature" :

  gpg : Signature made Thu 13 Nov 2014 17:42:18 NZDT using RSA key ID 5590A237
  gpg : Good signature from "Matthieu Aubry <matt@piwik.org>"
  gpg :                 aka "Matthieu Aubry <matthieu.aubry@gmail.com>"
  gpg :                 aka "Matthieu Aubry <matt@piwik.pro>"
  

  Notice that there may be a warning in case you haven’t assigned a trust index to this person. This means that GnuPG verified that the key made that signature, but it’s up to you to decide if that key really belongs to the developer. The best method is to meet the developer in person and exchange key fingerprints.

  Mac OS X and Linux

  ---

  On Linux GnuPG is usually installed by default. On Mac OS X, you need to have GnuPG installed before you can verify signatures. You can install it from http://www.gpgtools.org/.

  Once it’s installed, use GnuPG to import the key that signed your package. Matthieu Aubry signs the Piwik releases. Import his key (814E346FA01A20DBB04B6807B5DBD5925590A237) by starting the terminal (under "Applications") and typing :

  gpg —keyserver keys.gnupg.net —recv-keys 814E346FA01A20DBB04B6807B5DBD5925590A237

  After importing the key, you can verify that the fingerprint is correct :

  gpg —fingerprint 814E346FA01A20DBB04B6807B5DBD5925590A237

  You should see :

  pub   4096R/5590A237 2013-07-24
        Key fingerprint = 814E 346F A01A 20DB B04B  6807 B5DB D592 5590 A237
  uid                  Matthieu Aubry <matt@piwik.org>
  uid                  Matthieu Aubry <matthieu.aubry@gmail.com>
  uid                  Matthieu Aubry <matt@piwik.pro>
  sub   4096R/43F0D330 2013-07-24
  

  To verify the signature of the package you downloaded, you will need to download the ".asc" file as well. Assuming you downloaded the package and its signature to your Desktop, run :

  gpg —verify /Users/Alice/piwik-2.9.0.zip.asc*,

  The output should say "Good signature" :

  gpg : Signature made Thu 13 Nov 2014 17:42:18 NZDT using RSA key ID 5590A237
  gpg : Good signature from "Matthieu Aubry <matt@piwik.org>"
  gpg :                 aka "Matthieu Aubry <matthieu.aubry@gmail.com>"
  gpg :                 aka "Matthieu Aubry <matt@piwik.pro>"
  

  Notice that there may be a warning in case you haven’t assigned a trust index to this person. This means that GnuPG verified that the key made that signature, but it’s up to you to decide if that key really belongs to the developer. The best method is to meet the developer in person and exchange key fingerprints.

  That’s it ! In this article you have learnt how you can verify that the Piwik package you have downloaded on your computer was the same as the one Piwik team has officially created. We hope this helps you use Piwik with more security.

  Source : this article was copied and adapted from the great Tor Browser project website page How to verify signatures for Tor packages

• Troubleshooting ffmpeg/ffplay client RTSP RTP UDP * multicast * issue

  6 novembre 2020, par MAXdB

  I'm having problem with using udp_multicast transport method using ffmpeg or ffplay as a client to a webcam.

  


  TCP transport works :

  


  ffplay -rtsp_transport tcp rtsp://192.168.1.100/videoinput_1/mjpeg_3/media.stm


  


  UDP transport works :

  


  ffplay -rtsp_transport udp rtsp://192.168.1.100/videoinput_1/mjpeg_3/media.stm


  


  Multicast transport does not work :

  


  ffplay -rtsp_transport udp_multicast rtsp://192.168.1.100/videoinput_1/mjpeg_3/media.stm


  


  The error message when udp_multicast is chosen reads :

  


  [rtsp @ 0x7fd6a8000b80] Could not find codec parameters for stream 0 (Video: mjpeg, none(bt470bg/unknown/unknown)): unspecified size


  


  Run with -v debug : Observe that the UDP multicast information appears in the SDP even though the chosen transport is unicast for this run. The SDP content is unchanged for unicast or multicast.

  


  [tcp @ 0x7f648c002f40] Starting connection attempt to 192.168.1.100 port 554
[tcp @ 0x7f648c002f40] Successfully connected to 192.168.1.100 port 554
[rtsp @ 0x7f648c000b80] SDP:
v=0
o=- 621355968671884050 621355968671884050 IN IP4 192.168.1.100
s=/videoinput_1:0/mjpeg_3/media.stm
c=IN IP4 0.0.0.0
m=video 40004 RTP/AVP 26
c=IN IP4 237.0.0.3/1
a=control:trackID=1
a=range:npt=0-
a=framerate:25.0

Failed to parse interval end specification ''
[rtp @ 0x7f648c008e00] No default whitelist set
[udp @ 0x7f648c009900] No default whitelist set
[udp @ 0x7f648c009900] end receive buffer size reported is 425984
[udp @ 0x7f648c019c80] No default whitelist set
[udp @ 0x7f648c019c80] end receive buffer size reported is 425984
[rtsp @ 0x7f648c000b80] setting jitter buffer size to 500
[rtsp @ 0x7f648c000b80] hello state=0
Failed to parse interval end specification ''
[mjpeg @ 0x7f648c0046c0] marker=d8 avail_size_in_buf=145103 
[mjpeg @ 0x7f648c0046c0] marker parser used 0 bytes (0 bits)
[mjpeg @ 0x7f648c0046c0] marker=e0 avail_size_in_buf=145101
[mjpeg @ 0x7f648c0046c0] marker parser used 16 bytes (128 bits)
[mjpeg @ 0x7f648c0046c0] marker=db avail_size_in_buf=145083
[mjpeg @ 0x7f648c0046c0] index=0
[mjpeg @ 0x7f648c0046c0] qscale[0]: 5
[mjpeg @ 0x7f648c0046c0] index=1
[mjpeg @ 0x7f648c0046c0] qscale[1]: 10
[mjpeg @ 0x7f648c0046c0] marker parser used 132 bytes (1056 bits)
[mjpeg @ 0x7f648c0046c0] marker=c4 avail_size_in_buf=144949
[mjpeg @ 0x7f648c0046c0] marker parser used 0 bytes (0 bits)
[mjpeg @ 0x7f648c0046c0] marker=c0 avail_size_in_buf=144529
[mjpeg @ 0x7f648c0046c0] Changing bps from 0 to 8
[mjpeg @ 0x7f648c0046c0] sof0: picture: 1920x1080
[mjpeg @ 0x7f648c0046c0] component 0 2:2 id: 0 quant:0
[mjpeg @ 0x7f648c0046c0] component 1 1:1 id: 1 quant:1
[mjpeg @ 0x7f648c0046c0] component 2 1:1 id: 2 quant:1
[mjpeg @ 0x7f648c0046c0] pix fmt id 22111100
[mjpeg @ 0x7f648c0046c0] Format yuvj420p chosen by get_format().
[mjpeg @ 0x7f648c0046c0] marker parser used 17 bytes (136 bits)
[mjpeg @ 0x7f648c0046c0] escaping removed 676 bytes
[mjpeg @ 0x7f648c0046c0] marker=da avail_size_in_buf=144510
[mjpeg @ 0x7f648c0046c0] marker parser used 143834 bytes (1150672 bits)
[mjpeg @ 0x7f648c0046c0] marker=d9 avail_size_in_buf=2
[mjpeg @ 0x7f648c0046c0] decode frame unused 2 bytes
[rtsp @ 0x7f648c000b80] All info found vq=    0KB sq=    0B f=0/0
[rtsp @ 0x7f648c000b80] rfps: 24.416667 0.018101
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 24.500000 0.013298
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 24.583333 0.009235
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 24.666667 0.005910
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 24.750000 0.003324
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 24.833333 0.001477
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 24.916667 0.000369
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 25.000000 0.000000
[rtsp @ 0x7f648c000b80] rfps: 25.083333 0.000370
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 25.166667 0.001478
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 25.250000 0.003326
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 25.333333 0.005912
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 25.416667 0.009238
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 25.500000 0.013302
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 25.583333 0.018105
    Last message repeated 1 times
[rtsp @ 0x7f648c000b80] rfps: 50.000000 0.000000
[rtsp @ 0x7f648c000b80] Setting avg frame rate based on r frame rate
Input #0, rtsp, from 'rtsp://192.168.1.100/videoinput_1/mjpeg_3/media.stm':
  Metadata:
    title           : /videoinput_1:0/mjpeg_3/media.stm
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0, 21, 1/90000: Video: mjpeg (Baseline), 1 reference frame, yuvj420p(pc, bt470bg/unknown/unknown, center), 1920x1080 [SAR 1:1 DAR 16:9], 0/1, 25 fps, 25 tbr, 90k tbn, 90k tbc
[mjpeg @ 0x7f648c02ad80] marker=d8 avail_size_in_buf=145103


  


  Here is the same debug section when using udp_multicast. The SDP is identical as mentioned, and the block after the SDP containing [mjpeg] codec info is entirely missing (beginning with marker=d8)—the stream is never identified. This happens (to the eye) instantaneously, there's no indication of a timeout waiting unsuccessfully for an RTP packet, though this, too, could just be insufficient debug info in the driver. Also note that ffmpeg knows that the frames are MJPEG frames and the color primaries are PAL, it just doesn't know the size. Also curious, but not relevant to the problem, the unicast UDP transport destination port utilized for the stream does not appear in the ffmpeg debug dump shown above, meaning part of the RTSP/RTP driver is hiding important information under the kimono, that port number and how it knows that the frames will be MJPEG.

  


  [tcp @ 0x7effe0002f40] Starting connection attempt to 192.168.1.100 port 554
[tcp @ 0x7effe0002f40] Successfully connected to 192.168.1.100 port 554
[rtsp @ 0x7effe0000b80] SDP:aq=    0KB vq=    0KB sq=    0B f=0/0
v=0
o=- 621355968671884050 621355968671884050 IN IP4 192.168.1.100
s=/videoinput_1:0/mjpeg_3/media.stm
c=IN IP4 0.0.0.0
m=video 40004 RTP/AVP 26
c=IN IP4 237.0.0.3/1
a=control:trackID=1
a=range:npt=0-
a=framerate:25.0

Failed to parse interval end specification ''
[rtp @ 0x7effe0008e00] No default whitelist set
[udp @ 0x7effe0009900] No default whitelist set
[udp @ 0x7effe0009900] end receive buffer size reported is 425984
[udp @ 0x7effe0019c40] No default whitelist set
[udp @ 0x7effe0019c40] end receive buffer size reported is 425984
[rtsp @ 0x7effe0000b80] setting jitter buffer size to 500
[rtsp @ 0x7effe0000b80] hello state=0
Failed to parse interval end specification '' 
[rtsp @ 0x7effe0000b80] Could not find codec parameters for stream 0 (Video: mjpeg, 1 reference frame, none(bt470bg/unknown/unknown, center)): unspecified size
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
Input #0, rtsp, from 'rtsp://192.168.1.100/videoinput_1/mjpeg_3/media.stm':
  Metadata:
    title           : /videoinput_1:0/mjpeg_3/media.stm
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0, 0, 1/90000: Video: mjpeg, 1 reference frame, none(bt470bg/unknown/unknown, center), 90k tbr, 90k tbn, 90k tbc
    nan M-V:    nan fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0


  


  This is the TCPDUMP of the traffic. The information in both streams appears identical.

  


  19:21:30.703599 IP 192.168.1.100.64271 > 192.168.1.98.5239: UDP, length 60
19:21:30.703734 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 1400
19:21:30.703852 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 1400
19:21:30.704326 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 1400
19:21:30.704326 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 1400
19:21:30.704327 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 1400
19:21:30.704327 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 1400
19:21:30.704504 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 1400
19:21:30.704813 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 1400
19:21:30.704814 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 1400
19:21:30.704872 IP 192.168.1.100.64270 > 192.168.1.98.5238: UDP, length 732
19:21:30.704873 IP 192.168.1.100.59869 > 237.0.0.3.40005: UDP, length 60
19:21:30.705513 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 1400
19:21:30.705513 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 1400
19:21:30.705513 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 1400
19:21:30.705513 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 1400
19:21:30.705594 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 1400
19:21:30.705774 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 1400
19:21:30.706236 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 1400
19:21:30.706236 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 1400
19:21:30.706236 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 1400
19:21:30.706236 IP 192.168.1.100.59868 > 237.0.0.3.40004: UDP, length 732


  


  I hope this is a configuration problem, that I can fix this in my ffplay/ffmpeg line, and it's not a bug in ffmpeg. Thanks for any tips.

  


• Is there a way to force ffmpeg produce an I frame while encoding a mjpeg stream to h264

  2 novembre 2020, par SolskGaer

  I am transcoding a mjpeg stream to a h264 one, and I hope the stream can be played anytime I put it to a player, as far as I know, I need an I-frame the time I connect to it to play the stream properly, is it possible ? By the way, I invoke the ffmpeg binary using golang so I have full control of its input.