Nous avons le plaisir de vous informer que, dans les conditions sanitaires actuelles, la 12e édition de l'Asso de Rouen (le Forum des Associations) 2020 se tiendra le 5 septembre prochain de 10h à 18h sur les quais bas rive gauche (sur les espaces sportifs au niveau du Pont Guillaume le Conquérant). Cet espace, plus […]

The post A l’asso de Rouen 2020 – Forum des associations appeared first on Network Users Institute - Cybersécurité, Intégration de Linux & Logiciels Libres à Rouen, Normandie..

Saya memiliki satu set CCTV beserta DVRnya. Mereknya Nathans, sponsor dari kantor (PT SKK). Ini CCTV asli ndak pakai ribet, just work. Nah … PRnya adalah gimana caranya nyambungin ke Shinobi. Berminggu-minggu saya gak berhasil menemukan solusinya. Sampai saya menyerah.

Sekitar 2 mingguan lalu, saya tiba-tiba nemu sebuah saran url rtsp dari internet. Dan saya coba beneran bisa. Berikut urlnya:

rtsp://192.168.0.3:554/user=admin&password=passwordmu&channel=1&stream=1.sdp?real_stream–rtp-caching=100

Silahkan sesuaikan alamat IP beserta akun yang ada di DVR Anda.

Hoy toca entrada recurrente ya que llegamos a la actualización mensual de rigor que demuestra que los desarrolladores de KDE no dejan de trabajar ni encerrados en sus casa. Así que se congratulan en anunciar la actualización de junio del 2020 de KDE Frameworks.  Con esta se llega a la versión 5.71, un suma y sigue de compromiso y constancia que no parece que tenga un final cercano.

Actualización de junio del 2020 de KDE Frameworks

A pesar de que para los usuarios corrientes esta noticia sea algo confusa ya que no se trata de realzar una nueva aplicación ni de una nueva gran funcionalidad del escritorio, el desarrollo de KDE Frameworks tiene repercusiones directas en él a medio y largo plazo.

La razón de esta afirmación es que KDE Frameworks es básicamente la base de trabajo de los desarrolladores para realizar sus aplicaciones, es como el papel y las herramientas de dibujo para un artista: cuanto mejor sea el papel y mejores pinceles tenga, la creación de una artista será mejor.

De esta forma, las mejoras en KDE Frameworks facilitan el desarrollo del Software de la Comunidad KDE, haciendo que su funcionamiento, su estabilidad y su integración sea la mejor posible.

Ayer sábado 6 de junio de 2020 fue lanzado KDE Frameworks 5.71, la nueva revisión del entorno de programación sobre el que se asienta Plasma 5, el escritorio GNU/Linux de la Comunidad KDE, y las aplicaciones que se crean con para él.

Hay que recordar que los desarrolladores de KDE decidieron lanzar actualizaciones mensuales de este proyecto y lo están cumpliendo con puntualmente. La idea es ofrecer pocas pero consolidadas novedades, a la vez que se mantiene el proyecto evolucionando y siempre adaptándose al vertiginoso mundo del Software Libre.

Una gran noticia para la Comunidad KDE que demuestra la evolución continua del proyecto que continua ganando prestigio en el mundo de los entornos de trabajo Libres.

Más información: KDE

¿Qué es KDE Frameworks?

Para los que no lo sepan, KDE Frameworks añade más de 70 librerías a Qt que proporcionan una gran variedad de funcionalidades necesarias y comunes, precisadas por los desarrolladores, testeadas por aplicaciones especí­ficas y publicadas bajo licencias flexibles. Como he comentado, este entorno de programación es la base para el desarrollo tanto de las nuevas aplicaciones KDE y del escritorio Plasma 5.

Aquí podéis encontrar un listado con todos estos frameworks y la serie de artículos que dedico a KDE Frameworks en el blog,

Recuerda que puedes ver una introducción a Frameworks 5.0 en su anuncio de lanzamiento.

Tumbleweed es una distribución “Rolling Release” de actualización contínua. Aquí puedes estar al tanto de las últimas novedades.

openSUSE Tumbleweed es la versión “rolling release” o de actualización continua de la distribución de GNU/Linux openSUSE.

Hagamos un repaso a las novedades que han llegado hasta los repositorios estas semanas.

El anuncio original lo puedes leer en el blog de Dominique Leuenberger, publicado bajo licencia CC-by-sa, en este enlace:

• http://dominique.leuenberger.net/blog/2020/06/opensuse-tumbleweed-review-of-the-week-2020-24/

Otra semana que se pasa. Y en esta semana ha habido algunos problemas técnicos a la hora de publicar snapshots”. Dos fueron marcadas para ser publicadas, pero no llegaron a los servidores. En otra kiwi renombró las imágenes “live” de -i686- to -ix86-.  Así que debido a esto solo se han publicado 3 snapshots (0604, 0609 y 0610; 0609 contiene los cambios de 0605 y 0607 las snapshots que no llegaron a los servidores)

Los cambios más significativos en estas snapshots fueron:

• GNOME 3.36.3
• Mozilla Firefox 77.0.1
• Libvirt 6.4.0
• Transmission 3.00
• KDE Plasma 5.19.0

Y algunas cosas que se incluirán en próximas snapshots:

• KDE Applications 20.04.2
• SQLite 3.32.2
• Linux kernel 5.7.1
• Mesa 20.1.0
• RPM change
• openSSL 3.0

Si quieres estar a la última con software actualizado y probado utiliza openSUSE Tumbleweed la opción rolling release de la distribución de GNU/Linux openSUSE.

Mantente actualizado y ya sabes: Have a lot of fun!!

Enlaces de interés

• • • ¿Por qué deberías utilizar openSUSE Tumbleweed?
    • zypper dup en Tumbleweed hace todo el trabajo al actualizar
    • ¿Cual es el mejor comando para actualizar Tumbleweed?
    • Comprueba la valoración de las “snapshots” de Tumbleweed
    • ¿Qué es el test openQA?
    • http://download.opensuse.org/tumbleweed/iso/
    • https://es.opensuse.org/Portal:Tumbleweed

——————————–

Como sabréis, este año se Akademy 2020 se celebrará en línea del 4 al 11 de Septiembre. La entrada de hoy es para recordaros que el Call for Papers, es decir, la recepción de charlas está abierto, con lo que Akademy 2020 sigue esperando tu charla, si es que todavía no te has atrevido a presentarla.

Akademy 2020 sigue esperando tu charla ¡A qué esperas!

A pesar de todas las restricciones para vernos que tenemos debido a la pandemia, los eventos comunitarios parece que no se detienen.

El pasado 15 de abril compartí con vosotros que este año Akademy 2020 se realizaría en línea del 4 al 11 de septiembre, en una edición muy especial.

Siguiendo el esquema habitual, las charlas se realizarán en línea el sábado 5 y el domingo 6, dejando el resto de días para el trabajo en pequeños grupos en sala más reservadas pero no privadas, es decir, que no están cerradas sino que todo el que quiera aportar algo está invitdado.

Como se ha comentado en anteriores ocasiones, uno de los objetivos de Akademy es aprender y enseñar nuevos conocimientos y compartir entre nosotros la pasión de lo que se hace en KDE.

Para compartir ideas, experiencias o momentos, se reservan talleres específicos en la sede (o se aprovechan los corrillos en los pasillos, las cenas o los momentos de barra), pero para enseñar y compartir detalles técnicos se utilizan las charlas.

Si crees que tienes algo importante que presentar, por favor házselo saber a la organización. Y si crees que alguien debería presentar su ponencia, no dejes de animarlo para que lo haga. Todas las contribuciones son útiles.

Para más detalles, mira las líneas generales del Call for Papers. Tienes de plazo para enviar tu propuesta hasta el domingo 14 de Junio 23:59:59 CEST.

Vía: KDE News

¿Qué es Akademy?

Para los que no lo sepan, Akademy es el evento de la Comunidad KDE que aúna en una gran conferencia todo tipo de simpatizantes de KDE como desarrolladores, diseñadores, usuarios, traductores, promotores, ideólogos, etc. Allí se reunirán a lo largo de una semana para compartir charlas, cenas, ponencias, talleres y, en definitiva, para trabajar juntos.
Es una gran semana que sirve para unir más fuerte los lazos que unen nuestra Comunidad, así como para crear nuevos que se mantendran gracias a las listas de correo, canales irc o Sprints.

Hay que recordar que en España tenemos gran tradición en la celebración de Akademy ya que en 2005 se celebró en Málaga , en 2011 en Gran Canaria, en 2013 en Bilbao, en 2015 en A Coruña y en 2017 en Almería, todos esos años junto con Akademy-es (como este año), y que fue un gran éxito tanto de asistentes, como de ponencias o de resultados. Así que no tienes excusa para asistir ya que por el «precio» de uno este año tienes dos grandísimos eventos a tu alcance.

Dear Tumbleweed users and hackers,

Another week has passed. There have been a few technical issues around the publishing of our snapshots. Two were flagged for release, but actually never made it to the mirrors. Turned out, kiwi renamed some of the live-images from *-i686-* to *-ix86-*. But nothing else knew about it. As we even have links on the web pointing to those image names, we opted to revert to the original name. So, due to this, we only release 3 snapshots (0604, 0609, and 0610; 0609 contained the changes of 0605 and 0607 – the ones that got not synced out).

The changes in these snapshots were:

• GNOME 3.36.3 (sadly, upstream did not release a gnome-desktop update; this package would be responsible for the version number shown in the control center)
• Mozilla Firefox 77.0.1
• Libvirt 6.4.0
• Transmission 3.00
• KDE Plasma 5.19.0

Thins being worked on include:

• KDE Applications 20.04.2
• SQLite 3.32.2
• Linux kernel 5.7.1
• Mesa 20.1.0
• RPM change: %{_libexecdir} is being changed to /usr/libexec. This exposes quite a lot of packages that abuse %{_libexecdir} and fail to build
• openSSL 3.0

Hace un par de días que apareció la nueva versión del escritorio de la Comunidad KDE y ya es hora de empezar a hablar unde algunas novedades de Plasma 5.19, ahora que ya está disponible en algunas distribuciones, como KDE Neon, y he podido probarlo un poco.

Algunas novedades de Plasma 5.19

El pasado 9 de junio de 2020 fue lanzado Plasma 5.19, otro paso más en la evolución constante de este entorno de trabajo, y cuyo lanzamiento destacaba por la optimización de código, con lo cual se limaban las asperezas de las anteriores versiones.

No obstante, los desarrolladores de KDE no pueden ofrecer una nueva versión sin ofrecer novedades. El martes compartí una pincelada de ellas pero hoy es el momento de hacer una revisión un poco más pormenorizada.

Empezaré con las novedades del Escritorio, la uniformidad de aspecto y comportamiento de la bandeja del sistema y los plasmoides.

Escritorio y bandeja de sistema

Las primera de las novedades que encontramos es un cambio en el fondo de escritorio por defecto. Ahora es Flow, diseñado por Sandra Smukaste, que nos ofrece mucho color y contraste, en contraste con el tono pastel del anterior. Personalmente me gustaría que cada versión tuviera su fondo por defecto, para así poder diferenciar rápidamente cada lanzamiento.

También se han mejorado detalles que no se notan demasiado hasta que se trabaja mucho con el entorno. De esta forma el espaciador del panel, el elemento invisible que ayuda a situar componentes en el panel, puede ahora centrar automáticamente los plasmoides.

Por otra parte se ha completado la colección avatares por defecto para escoger cuando esté configurando su usuario, un pequeño detalle que siempre da un toque de profesionalidad a cualquier entorno.

Además, Plasma 5.19 incorpora un diseño consistente y un área de cabecera uniforme para las miniaplicaciones de la bandeja del sistema y para las notificaciones.

Para finalizar comentar que se ha mejorado la integración de aplicaciones No-KDE, como es el caso de las creadas con librerías GTK. De esta forma:

• Las aplicaciones GTK3 aplican inmediatamente los esquemas de color recién seleccionados.
• Las aplicaciones GTK2 ya no tienen colores estropeados y se ha aumentado el tamaño del tipo de letra de anchura fija de 9 a 10 puntos, mejorando la lectura de las mismas.

Los plasmoides también mejoran

Esos maravillosas miniaplicaciones que dan el extra de configuración a nuestro escritorio han sufrido pequeñas per significativas mejora.

De esta forma:

• Se ha refrescado el aspecto de la miniaplicación de reproducción multimedia de la bandeja del sistema
• Ampliado el control sobre la visibilidad de los controles de volumen, al tiempo que se ha limpiado y mejorado su aspecto, algo cada vez más importante ahora que todos vamos con auriculares y micrófonos variados.
• El plasmoide «Monitor del sistema» se han reescrito desde cero, ofreciendo un aspecto mucho más elegante y acorde con el escritorio.

• Se han resideñado las ayudas emergentes del gestor de tareas.
• Las notas adhesivas contienen varias mejoras de usabilidad.

Y no me canso de ver y compartir el vídeo promocional de este lanzamiento de Plasma 5.19.

Mañana más novedades, aunque si queréis verlas ya todas, os remito al anuncio oficial en al web oficial de KDE.

When Go 1.12 was released, I was very excited to test out the new opt-in support for TLS 1.3. TLS 1.3 is a major improvement to the main security protocol of the web.

I was eager to try it out in a tool I had written for work which allowed me to scan what TLS parameters were supported by a server. In TLS, the client presents a set of cipher suites to the server that it supports, and the server chooses the best one to use, where “best” is typically a reasonable trade-off of security and performance.

In order to enumerate what cipher suites a server supports, a client must make individual connections, each offering a single cipher suite at a time. If the server rejects the handshake, you know the cipher suite is not supported.

For TLS 1.2 and below, this is pretty straightforward:

func supportedTLS12Ciphers(hostname string) []uint16 {
	// Taken from https://golang.org/pkg/crypto/tls/#pkg-constants
	var allCiphers = []uint16{
		tls.TLS_RSA_WITH_RC4_128_SHA,
		tls.TLS_RSA_WITH_3DES_EDE_CBC_SHA,
		tls.TLS_RSA_WITH_AES_128_CBC_SHA,
		tls.TLS_RSA_WITH_AES_256_CBC_SHA,
		tls.TLS_RSA_WITH_AES_128_CBC_SHA256,
		tls.TLS_RSA_WITH_AES_128_GCM_SHA256,
		tls.TLS_RSA_WITH_AES_256_GCM_SHA384,
		tls.TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,
		tls.TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
		tls.TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
		tls.TLS_ECDHE_RSA_WITH_RC4_128_SHA,
		tls.TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
		tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
		tls.TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
		tls.TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
		tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
		tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
		tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
		tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
		tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
		tls.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
		tls.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,
	}

    var supportedCiphers []uint16
    
	for _, c := range allCiphers {
		cfg := &tls.Config{
			ServerName:   hostname,
			CipherSuites: []uint16{c},
			MinVersion:   tls.VersionTLS12,
			MaxVersion:   tls.VersionTLS12,
		}

		conn, err := net.Dial("tcp", hostname+":443")
		if err != nil {
			panic(err)
		}

		client := tls.Client(conn, cfg)
		client.Handshake()
		client.Close()

		if client.ConnectionState().CipherSuite == c {
			supportedCiphers = append(supportedCiphers, c)
		}
	}

	return supportedCiphers
}

After writing the barebones code to support TLS 1.3 in the tool, I discovered something unfortunate: Go does not allow you to select what TLS 1.3 cipher suites are sent to the server. The rationale makes sense: TLS 1.3 greatly simplified both what is contained within a cipher suite and how many are supported. Unless and until there is a weakness in a TLS 1.3 cipher suite, there’s nothing to be gained in allowing them to be customized.

Still, this tool was one of the rare situations where it makes sense, and I wanted to see if I could hack it in. Enter go:linkname. Buried deep in Go’s compiler documentation:

//go:linkname localname importpath.name

The //go:linkname directive instructs the compiler to use “importpath.name” as the object file symbol name for the variable or function declared as “localname” in the source code. Because this directive can subvert the type system and package modularity, it is only enabled in files that have imported “unsafe”.

Well hello! This looks promising. If there is a function or variable in Go’s standard library that specifies what the list of TLS 1.3 ciphers are, we can override that in our tool by instructing the Go complier to use our local implementation instead of the one in the standard library.

Let’s dig into the standard library’s TLS 1.3 implementation. In crypto/tls/handshake_client.go [link], we have:

if hello.supportedVersions[0] == VersionTLS13 {
		hello.cipherSuites = append(hello.cipherSuites, defaultCipherSuitesTLS13()...)
        // ...
}

Great! Let’s just override this defaultCipherSuitesTLS13() function. In crypto/tls/common.go [link]:

func defaultCipherSuitesTLS13() []uint16 {
	once.Do(initDefaultCipherSuites)
	return varDefaultCipherSuitesTLS13
}

This complicates things a bit. This calls an initialization function lazily on first use, and that function manipulates a bunch of internal default lists beyond just the TLS 1.3 cipher suites list. We don’t want to mess with any of that. But in that initDefaultCipherSuites function, we have this [link]:

varDefaultCipherSuitesTLS13 = []uint16{
    TLS_AES_128_GCM_SHA256,
    TLS_CHACHA20_POLY1305_SHA256,
    TLS_AES_256_GCM_SHA384,
}

Ah ha! A package global variable is assigned the cipher suite values. And because this initialization function is only ever called once, we can initialize the list and then take control of it in our code.

// Using go:linkname requires us to import unsafe
import (
    "crypto/tls"
    _ "unsafe" 
)

// We bring the real defaultCipherSuitesTLS13 function from the
// crypto/tls package into our own package.  This lets us perform
// that lazy initialization of the cipher list when we want.

//go:linkname defaultCipherSuitesTLS13 crypto/tls.defaultCipherSuitesTLS13
func defaultCipherSuitesTLS13() []uint16

// Next we bring the `varDefaultCipherSuitesTLS13` slice into our
// package.  This is what we manipulate to get the cipher suites.

//go:linkname varDefaultCipherSuitesTLS13 crypto/tls.varDefaultCipherSuitesTLS13
var varDefaultCipherSuitesTLS13 []uint16

// Also keep a variable around for the real default set, so we
// can reset it once we're finished.
var realDefaultCipherSuitesTLS13 []uint16

func init() {
    // Initialize the TLS 1.3 ciphersuite set; this populates
    // varDefaultCipherSuitesTLS13 under the covers
    realDefaultCipherSuitesTLS13 = defaultCipherSuitesTLS13()
}

func supportedTLS13Ciphers(hostname string) []uint16 {
	var supportedCiphers []uint16

	for _, c := range realDefaultCipherSuitesTLS13 {
		cfg := &tls.Config{
			ServerName: hostname,
			MinVersion: tls.VersionTLS13,
		}

		// Override the internal slice!
		varDefaultCipherSuitesTLS13 = []uint16{c}

		conn, err := net.Dial("tcp", hostname+":443")
		if err != nil {
			panic(err)
		}

        client := tls.Client(conn, cfg)
		client.Handshake()
		client.Close()

		if client.ConnectionState().CipherSuite == c {
			supportedCiphers = append(supportedCiphers, c)
		}
	}

	// Reset the internal slice back to the full set
	varDefaultCipherSuitesTLS13 = realDefaultCipherSuitesTLS13

	return supportedCiphers
}

As you can see, we used go:linkname to subvert package modularity for both a function and a variable. We use a package init function to populate the default cipher suites list, and then we override it as we iterate and attempt connections with only a single supported cipher suite. Finally, we make sure to clean things up and set the default list back to the full set for any future uses.

Lastly, let’s glue things together:

func main() {
    hostname := os.Args[1]
	fmt.Println("Supported TLS 1.2 ciphers")
	for _, c := range supportedTLS12Ciphers(hostname) {
		fmt.Printf("  %s\n", tls.CipherSuiteName(c))
	}
	fmt.Println()
	fmt.Println("Supported TLS 1.3 ciphers")
	for _, c := range supportedTLS13Ciphers(hostname) {
		fmt.Printf("  %s\n", tls.CipherSuiteName(c))
	}
}

$ go run cipherlist.go joeshaw.org
Supported TLS 1.2 ciphers
  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Supported TLS 1.3 ciphers
  TLS_AES_128_GCM_SHA256
  TLS_CHACHA20_POLY1305_SHA256
  TLS_AES_256_GCM_SHA384

There you have it.

go:linkname should be used very sparingly. Consider carefully whether you must use it, or whether you can solve your problem another way. For me, the alternative was to import all of crypto/tls to make some minor edits. It would also freeze me into a point in time of the Go TLS stack and put the burden of upgrading onto me. While I know that there are no compatibility guarantees with Go’s crypto/tls internals, using go:linkname allows me to use the TLS stack provided by current and future versions of Go as long as the particular pieces I am using don’t change. I can live with that.

The full code for this test program lives in this Github repository.