tde-users

users@trinitydesktop.org

20 participants
4366 discussions

Trinity SSL Certificate Status
by Timothy Pearson 17 Feb '17

17 Feb '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224 I just wanted to let you know that the new TDE site SSL certificates have been installed. They are valid until 2020 so we should be good to go for quite some time. QuickBuild is handled somewhat outside of the TDE project itself, but should also be updated in the next month or so. Thank you all again for helping resolve this issue so quickly! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iFYEARELAAYFAliniqMACgkQLaxZSoRZrGHZzwDeMOYKZ/iiC6ZaMaIVXwsXOo0L pprznl0vuy/M4QDgtInLknauKmFtWc3Gmg8/0SQryDP5f/X/75cYOw== =yNSu -----END PGP SIGNATURE-----

1 0

Re: [trinity-users] Trinity SSL Certificates
by Dave Lers 17 Feb '17

17 Feb '17

Timothy Pearson wrote: > LetsEncrypt does not appear to be secure enough as it > effectively requires automated certificate installation on the > master servers, and furthermore I expect it to be removed from > as a fully trusted root CA or at least demoted in some way in the > future [3]. I'd suggest a little more research while paying attention to the originating source material (CA's who are losing money). At least one of the FUD sources in your link has been responded to: https://unmitigatedrisk.com/?p=552.

3 2

Re: [trinity-devel] Trinity SSL Certificates
by Timothy Pearson 16 Feb '17

16 Feb '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224 > Consider it done. > > Calvin And with that we're good to go! I'll order the replacement certificates shortly, which should reactivate TDE under all major browsers. Thank you all very much for stepping up and helping fix this, I greatly appreciate it! Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iFYEARELAAYFAlimXdwACgkQLaxZSoRZrGEgFQDgp6Kl+GwPIXNiCdDbjTtm0o+l wiT/uPSOWQWX0ADaAjn85+nk3UsGkbp7guXH/3pUc7Ij8kwbMiGeGA== =/HH8 -----END PGP SIGNATURE-----

1 0

Trinity SSL Certificates
by Timothy Pearson 16 Feb '17

16 Feb '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224 As some of you may already be aware, StartCom (a major provider of SSL certificates) has repeatedly and intentionally violated the basic rules to be listed as a root CA in most browsers [1] [2]. Unfortunately, TDE used StartCom as its root CA provider in an attempt to lower overall costs; as a result, the main TDE pages, QuickBuild, and other related services will no longer be accessible to the majority of Web clients. We do not have the funds to replace the certificate with a costlier option at this time. LetsEncrypt does not appear to be secure enough as it effectively requires automated certificate installation on the master servers, and furthermore I expect it to be removed from as a fully trusted root CA or at least demoted in some way in the future [3]. Due to the industry-standard security in use, we cannot simply disable HTTPS without disabling access to all TDE sites previously using HTTPS. Furthermore, disabling HTTPS would open TDE users adn visitors to malicious MITM attack, and I am not willing to do this. Our only options come down to either accepting the heavy loss in visitors / traffic that will come from using a self-signed certificate, or attempting to raise the funds required to purchase a new certificate. It should only cost around $200 to obtain a new multi-year certificate covering TDE, so if you can please contribute something toward this goal via our donations page [4]. Again, I apologize for the inconvenience; it is not common for a CA to be delisted and the impact from this has been felt across many sites. Unfortunately, it will only continue to worsen as Chrome (with its 75% market share) is updated by end users over the next few days / weeks. Thank you! [1] https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html [2] https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-sta… [3] http://www.datamation.com/security/lets-encrypt-the-good-and-the-bad.html [4] https://trinitydesktop.org/donate.php -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iFYEARELAAYFAlimAWgACgkQLaxZSoRZrGEmvgDgiRW0d0/yTuzseNQm7of0gzMz WPJSiyQPYpvBKQDgpU4QtQdAQ9ZIhjUBbzNTY/DgBBRmd53/P6QZsQ== =U7kv -----END PGP SIGNATURE-----

1 0

TDE NetworkManager frontend not working. Got "unable to perform requested operation". ConsoleKit (rly needed?) and PolicyKit are installed.
by Richard Lamboj 14 Feb '17

14 Feb '17

Hello, i can not use the tde network-manager frontend. A Message-Box pops up and says: Unable to save network connection! Potential causes: * Insufficient permissions * NetworkManager not running * DBUS failure Beside that i think the Assistent should not be closed. Both - ConsoleKit and PolicyKit - are installed. And i'm using OpenRC, not systemd on Debian Jessie, with backports enabled. Kind Regards, Richard

2 1

r14-xdg-update
by Leslie Turriff 11 Feb '17

11 Feb '17

Last week when I started my newest machine (x86_64 intel, OpenSuSE Leap 42.2), when logging in I got a notification box that said, The r14-xdg-update script has been run at least once. The script is not successfully updating. The script will run with each login until corrected. Please contact an administrator or take appropriate administrative action to correct the problem. The error code is 9. When I continued on, all of my Trinity desktop settings were gone. Rebooting does not help, nor did reinstalling the OS and Trinity. I have no idea what "appropriate administrative action" might be, nor what error code 9 means. Help! Leslie

1 0

multiple monitors
by Gene Kodadek 09 Feb '17

09 Feb '17

Can somebody give me a guide to getting a multi-monitor setup working using the native tools? I'm on Debian Jessie if that makes a difference. I had it working on a PCLInux OS install but can't remember how I did it.

2 1

digikam dependency conflict in openSSUE 13.2
by Istvan Gabor 09 Feb '17

09 Feb '17

YaST reports dependency conflict: #### YaST2 conflicts list - generated 2017-02-09 21:06:35 #### nothing provides trinity-digikam = 0.9.6-14.0.4_1.oss132 needed by trinity-digikam-i18n-2:0.9.6-14.0.4_1.oss132.x86_64 [ ] deinstallation of trinity-digikam-i18n-2:0.9.6-14.0.4_1.oss132.x86_64 [ ] break trinity-digikam-i18n-2:0.9.6-14.0.4_1.oss132.x86_64 by ignoring some of its dependencies #### YaST2 conflicts list END ### Though I have both above packages installed: > rpm -qa|grep digikam trinity-digikam-i18n-0.9.6-14.0.4_1.oss132.x86_64 trinity-digikam-0.9.6-14.0.4_1.oss132.x86_64 I have deleted and reinstalled the packages but always get the error. Istvan

2 1

digikam crash
by Istvan Gabor 09 Feb '17

09 Feb '17

Hello: Digikam crashes when in image editor I right click the images or try to select area. This occurs in openSUSE 13.2 Trinty TDE R14.0.4 64 bit. Digikam is trinity-digikam-0.9.6-14.0.4_1.oss132.x86_64. It does not occur with all images, only if the resolutions or file size is over a limit, though I don't know the limit. It occurs with jpg file 3264x2448 resolution ~1.8 MB, but it doesn't occur if I downsize this image to 1500x1125 ~500 KB. Does anyone have this problem? Could it be fixed? Thanks, Istvan

1 0

Re: [trinity-users] Re: Application resolution vs desktop resolution
by Thierry de Coulon 08 Feb '17

08 Feb '17

On Wednesday 08 February 2017 21.56:32 deloptes wrote: > Thierry de Coulon wrote: > > My problem is this: while I have the screen resolution setup to 1920x1080 > > (and trinity desktop looks OK for this resolution), the monitor (which is > > accessed from HDMI through an HDMI to VGA converter because I use a KVM > > that needs VGA connectors) was initially "seen" as 1024x768. > > It is interesting to know what is the output of xrandr > > I have/had similar issues with my notebook(s) and external monitor. > Natively eDP1 supports 1366x768, while monitor does 1920x1080. > > So switching on and of the one and the other messed up from time to time > the modesettings and I end up with unusable resolution. The external would > refuse to accept 1920x1080. It improved recently with later 4.9 kernel and > I did not test extensively. > One option was to configure monitors in xorg.conf with their mod lines. I > did this on the older notebook > I however use now xrandr --scale as X tends to pick up the lowest common > and it can not support different resolutions or whatever. So I put the > bigger one to 1920x1080 and scale eDP1., which gives acceptable output. > > I have read of similar issues with KVM. > > regards > That's what I get: Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 DP1 disconnected (normal left inverted right x axis y axis) HDMI1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 256mm x 192mm 1024x768 60.00 + 1920x1080 60.00* 59.94 1280x1024 85.02 60.02 1440x900 74.98 59.90 1280x960 60.00 1360x768 60.02 1280x800 59.91 1280x720 119.99 60.00 59.94 720x480 60.00 59.94 To me it seems the chipset by itself can do a lot of resolutions. I am new to HDMI (I actually don't use it anwhere as I have no monitor with such a connector). So I can't test what would happen if I had a direct connection to the monitor. I could imagine that the chain HDMI - HDMI to VGA (cheap chinese thing, by the way) - KVM switch - monitor is too much for a system that desperately tries to identify the monitor by itself. In the old time I would have been asked what my screen was... Thierry

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

tde-users