openvpn-devel Mailing List for OpenVPN

Hi, We're having an IRC meeting today, starting at 15:00 UTC on #ope...@ir.... Current topic list is here: <https://community.openvpn.net/openvpn/wiki/Topics-2012-05-31> If you have any other things you'd like to bring up, respond to this mail, send me mail privately or add them to the list yourself. In case you can't attend the meeting, please feel free to make comments on the topics by responding to this email or to the summary email sent after the meeting. Whenever possible, we'll also respond to existing, related email threads. NOTE: It's required to use a registered Freenode IRC nickname to join #openvpn-devel - look here for details: <https://community.openvpn.net/openvpn/wiki/GettingHelp#DeveloperIRCchannel> NOTE: there's already a lot to discuss, so please don't add any major topics to this week's agenda. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

Hi, I will translate it to simplified chinese as well, but might be send to you end of June. Thank you for your helping! On 05/23/12, Heiko Hund <hei...@so...> wrote: > On Thursday 17 May 2012 19:06:06 Yi-Wen Cheng wrote: > > I just finished both of files for translating to traditional chinese. > > Took me a little while, but I just finished integrating it into the GUI. Don't > know what .lang file is for, but I suppose it's another project you contribute > translation to. The .rc file is now part of the official OpenVPN-GUI. Thanks > for your efforts! > > > Btw,how can I see the new GUI of traditional chinese on my laptop? > > I released a new snapshot binary. You should be able to download it once it's > spread across the Sourceforge download mirrors at > http://sf.net/projects/openvpn-gui/files/Snapshot%20Binaries/2012-05-22/ > > Will you do the translation to Simplified Chinese as well? Is so, please base > it on the openvpn-gui-res-zh-hant.rc file in the repository. I made some > changes to the one you sent. > > Thanks again > Heiko > -- > Heiko Hund | Software Engineer | Tel +49-721-25516-237 | Fax -200 > SOPHOS NSG | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany > > > 

Adding integration tests that needs and/or manual intervention to make check is not something that should be encouraged. Tiered of arguing. But if you add this, at least use the following. --- tests/Makefile.am | 11 ++++++----- tests/t_client.sh.in | 13 ++++++++----- 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index 6ae845b..f6d9d1b 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -12,13 +12,14 @@ MAINTAINERCLEANFILES = \	$(srcdir)/Makefile.in -test_scripts = t_lpback.sh t_cltsrv.sh +test_scripts = t_lpback.sh t_cltsrv.sh t_client.sh -TESTS_ENVIRONMENT = top_srcdir="$(top_srcdir)" +TESTS_ENVIRONMENT = \ +	top_srcdir="$(top_srcdir)" \ +	top_builddir="$(top_builddir)" \ +	builddir="$(builddir)" TESTS = $(test_scripts) dist_noinst_SCRIPTS = \	$(test_scripts) \ -	t_cltsrv-down.sh \ -	t_client.sh - +	t_cltsrv-down.sh diff --git a/tests/t_client.sh.in b/tests/t_client.sh.in index 7ba124c..a9337a0 100755 --- a/tests/t_client.sh.in +++ b/tests/t_client.sh.in @@ -13,17 +13,20 @@ # srcdir="${srcdir:-.}" +builddir="${builddir:-${srcdir}}" top_builddir="${top_builddir:-..}" -if [ -r "${srcdir}"/t_client.rc ] ; then +if [ -r "${builddir}"/t_client.rc ] ; then + . "${builddir}"/t_client.rc +elif [ -r "${srcdir}"/t_client.rc ] ; then . "${srcdir}"/t_client.rc else - echo "$0: cannot find 't_client.rc' in ('${srcdir}'). SKIPPING TEST." >&2 + echo "$0: cannot find 't_client.rc' in ('${srcdir}', '${builddir}'). SKIPPING TEST." >&2 exit 77 fi if [ ! -x "${top_builddir}/src/openvpn/openvpn" ] then - echo "no (executable) openvpn binary in current directory. FAIL." >&2 + echo "no (executable) openvpn binary in '${top_builddir}' directory. FAIL." >&2 exit 1 fi @@ -83,7 +86,7 @@ fail() get_ifconfig_route() { # linux / iproute2? (-> if configure got a path) - if [ "@IPROUTE@" != "ip" ] + if [ -n "@IPROUTE@" ] then	echo "-- linux iproute2 --"	@IPROUTE@ addr show | grep -v valid_lft @@ -236,7 +239,7 @@ do trap "$RUN_SUDO kill $opid ; trap - 0 ; exit 1" 1 2 3 15 echo "wait for connection to establish..." - sleep 10 + sleep ${SETUP_TIME_WAIT:-10} # test whether OpenVPN process is still there if $RUN_SUDO kill -0 $opid -- 1.7.3.4 

Hi, On Mon, May 28, 2012 at 03:08:11PM +0300, Samuli Seppänen wrote: > I don't really care what the make target is called. It could even be an > entirely different target. Buildslaves could easily run "make check" > followed by "make root-check", "make connection-test" or whatever. If > nobody outside the core project is supposed to run the connectivity > tests, I think separating them from "make check" would make sense. Nobody who hasn't set up a t_client.rc beforehand will be bothered by the client connectivity tests anyway - "make check" will tell him "rc file hasn't been set up, skipping test", and that's all of it. So while I can see some purity of argument here - in the end, it's wasting human life time on discussions again, and the time could be better spent on what's sorely missing right now: automated tests (unit tests, client system tests, server system tests). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

Il 28.05.2012 10:52, Gert Doering ha scritto: > Hi > > On Sun, May 27, 2012 at 11:36:57PM +0300, Alon Bar-Lev wrote: >> t_client.sh requires root/sudo privileges. >> "make check" should not assume any special privilege. >> Because of this it is removed from "make check". >> You can still run this by hand or we can add special target such as >> "make root-check" or similar. > There was agreement by the developers to *have* this, and no explicit > agreement to *remove* it - you got an ACK for the patch, but I'm fairly > sure that it was not made clear that you removed t_client.sh functionality > while moving stuff around, because otherwise you would have seen NAKs. It seems 34cb91 removed this functionality without explicitly mention anything about it. It was a massive patch that moved stuff around, which is why this change went unnoticed. Somebody please apply Gert's patch or provide an alternative patch, I'd need to setup connectivity tests for my buildslaves, too. I don't really care what the make target is called. It could even be an entirely different target. Buildslaves could easily run "make check" followed by "make root-check", "make connection-test" or whatever. If nobody outside the core project is supposed to run the connectivity tests, I think separating them from "make check" would make sense. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

Hi,   this is simple patch implementing internal openvpn ping over OCC channel.   Important difference of OCC ping (OCC_PING) to existing one is that this one is replied on the other side of the channel (with OCC_PING_REPLY),   thus making it possible to configure clients and server ping and ping-restart timeout differently.   This might be usefull if someone is trying to combine mobile and non-mobile clients on one openvpn server. Non-mobile clients might want to have   reliable link and ping more frequently compared to mobile clients that might not want this (ie. to save battery on android ;-).   OCC ping replaces 'normal' ping if activated via occ-ping directive, and thus fully integrates with all ping/ping-restart/... directives.   Additionaly I've implemented occ-ping-compat mode, that will send OCC_REQUEST instread of OCC_PING. All OCC clients will then reply to this   request with OCC_REPLY message - it might be usefull to enable this on server, to stay backward compatible with older non occ-ping clients.   Please review it ;) Thanks. Sam diff -ur openvpn-2.2.2/occ.c openvpn-2.2.2-dev/occ.c --- openvpn-2.2.2/occ.c	2011-12-13 17:58:56.000000000 +0100 +++ openvpn-2.2.2-dev/occ.c	2012-05-27 19:23:15.000000000 +0200 @@ -302,6 +302,29 @@ dmsg (D_PACKET_CONTENT, "SENT OCC_EXIT"); doit = true; break; + + case OCC_PING: + if (c->options.occ_ping_compat) + { + if (!buf_write_u8 (&c->c2.buf, OCC_REQUEST)) + break; + dmsg (D_PACKET_CONTENT, "SENT OCC_REQUEST (compat OCC_PING)"); + } + else + { + if (!buf_write_u8 (&c->c2.buf, OCC_PING)) + break; + dmsg (D_PACKET_CONTENT, "SENT OCC_PING"); + } + doit = true; + break; + + case OCC_PING_REPLY: + if (!buf_write_u8 (&c->c2.buf, OCC_PING_REPLY)) +	break; + dmsg (D_PACKET_CONTENT, "SENT OCC_PING_REPLY"); + doit = true; + break; } if (doit) @@ -384,6 +407,14 @@ c->sig->signal_received = SIGTERM; c->sig->signal_text = "remote-exit"; break; + + case OCC_PING: + dmsg (D_PACKET_CONTENT, "RECEIVED OCC_PING"); + c->c2.occ_op = OCC_PING_REPLY; + break; + case OCC_PING_REPLY: + dmsg (D_PACKET_CONTENT, "RECEIVED OCC_PING_REPLY"); + break; } c->c2.buf.len = 0; /* don't pass packet on */ } diff -ur openvpn-2.2.2/occ.h openvpn-2.2.2-dev/occ.h --- openvpn-2.2.2/occ.h	2011-04-26 10:33:04.000000000 +0200 +++ openvpn-2.2.2-dev/occ.h	2012-05-25 23:07:18.000000000 +0200 @@ -70,6 +70,13 @@ #define OCC_EXIT 6 /* + * OCC based ping + */ +#define OCC_PING	7 +#define OCC_PING_REPLY	8 + + +/* * Used to conduct a load test command sequence * of UDP connection for empirical MTU measurement. */ diff -ur openvpn-2.2.2/options.c openvpn-2.2.2-dev/options.c --- openvpn-2.2.2/options.c	2011-12-13 17:58:56.000000000 +0100 +++ openvpn-2.2.2-dev/options.c	2012-05-25 23:20:55.000000000 +0200 @@ -229,6 +229,11 @@ "--ping-timer-rem: Run the --ping-exit/--ping-restart timer only if we have a\n" " remote address.\n" "--ping n : Ping remote once every n seconds over TCP/UDP port.\n" +#ifdef ENABLE_OCC + "--occ-ping : Ping using internal OCC protocol.\n" + "--occ-ping-compat : Use backward compatible OCC ping.\n" + " Use for clients without occ-ping support.\n" +#endif #if ENABLE_IP_PKTINFO "--multihome : Configure a multi-homed UDP server.\n" #endif @@ -1235,8 +1240,11 @@ SHOW_BOOL (ping_timer_remote); SHOW_INT (remap_sigusr1); #ifdef ENABLE_OCC + SHOW_BOOL (occ_ping); + SHOW_BOOL (occ_ping_compat); SHOW_INT (explicit_exit_notification); #endif + SHOW_BOOL (persist_tun); SHOW_BOOL (persist_local_ip); SHOW_BOOL (persist_remote_ip); @@ -4529,6 +4537,16 @@ options->ping_timer_remote = true; } #ifdef ENABLE_OCC + else if (streq (p[0], "occ-ping")) + { + VERIFY_PERMISSION (OPT_P_TIMER); + options->occ_ping = true; + } + else if (streq (p[0], "occ-ping-compat")) + { + VERIFY_PERMISSION (OPT_P_TIMER); + options->occ_ping_compat = true; + } else if (streq (p[0], "explicit-exit-notify")) { VERIFY_PERMISSION (OPT_P_EXPLICIT_NOTIFY); diff -ur openvpn-2.2.2/options.h openvpn-2.2.2-dev/options.h --- openvpn-2.2.2/options.h	2011-12-13 17:58:56.000000000 +0100 +++ openvpn-2.2.2-dev/options.h	2012-05-25 23:04:14.000000000 +0200 @@ -239,6 +239,11 @@ int ping_send_timeout; /* Send a TCP/UDP ping to remote every n seconds */ int ping_rec_timeout; /* Expect a TCP/UDP ping from remote at least once every n seconds */ bool ping_timer_remote; /* Run ping timer only if we have a remote address */ +#ifdef ENABLE_OCC + bool occ_ping;	/* Enable OCC ping */ + bool occ_ping_compat;	/* Enable OCC ping compatibility mode */ +#endif + bool tun_ipv6; /* Build tun dev that supports IPv6 */ # define PING_UNDEF 0 diff -ur openvpn-2.2.2/ping-inline.h openvpn-2.2.2-dev/ping-inline.h --- openvpn-2.2.2/ping-inline.h	2011-04-26 10:33:04.000000000 +0200 +++ openvpn-2.2.2-dev/ping-inline.h	2012-05-27 18:50:40.000000000 +0200 @@ -53,7 +53,14 @@ && event_timeout_trigger (&c->c2.ping_send_interval,	&c->c2.timeval,	!TO_LINK_DEF(c) ? ETT_DEFAULT : 1)) - check_ping_send_dowork (c); + { +#ifdef ENABLE_OCC + if(c->options.occ_ping) + c->c2.occ_op = OCC_PING; + else +#endif + check_ping_send_dowork (c); + } } #endif 

Hi On Sun, May 27, 2012 at 11:36:57PM +0300, Alon Bar-Lev wrote: > t_client.sh requires root/sudo privileges. > "make check" should not assume any special privilege. > Because of this it is removed from "make check". > You can still run this by hand or we can add special target such as > "make root-check" or similar. There was agreement by the developers to *have* this, and no explicit agreement to *remove* it - you got an ACK for the patch, but I'm fairly sure that it was not made clear that you removed t_client.sh functionality while moving stuff around, because otherwise you would have seen NAKs. If someone wants to run it as non-root, RUN_SUDO can be defined in t_client.rc, and for someone having no provileges at all, you can just leave off t_client.rc, and it will skip these tests with no adverse effects. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

t_client.sh requires root/sudo privileges. "make check" should not assume any special privilege. Because of this it is removed from "make check". You can still run this by hand or we can add special target such as "make root-check" or similar. On Sun, May 27, 2012 at 11:27 PM, Gert Doering <ge...@gr...> wrote: > Hi, > > working on the test server, I noticed that t_client.sh was no longer run > from "make check", and that it lost "read t_client.rc from build dir" > (which is needed when building different clients from a common source > dir, and wanting to run t_client with different option sets). > > The attached patch restores lost functionality, and adds one extra > feature, optionally waiting longer for OpenVPN startup (if the server > has a high RTT, 10 seconds is not always enough). > > David, this has been tested on FreeBSD 7.4 (so far) and is essential > for the buildbot client tests :-) - more platform tests will follow > as soon as I have all the server stanzas up and running. > > gert > -- > USENET is *not* the non-clickable part of WWW! >                                                           //www.muc.de/~gert/ > Gert Doering - Munich, Germany                             ge...@gr... > fax: +49-89-35655025                        ge...@ne... > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > 

Hi, working on the test server, I noticed that t_client.sh was no longer run from "make check", and that it lost "read t_client.rc from build dir" (which is needed when building different clients from a common source dir, and wanting to run t_client with different option sets). The attached patch restores lost functionality, and adds one extra feature, optionally waiting longer for OpenVPN startup (if the server has a high RTT, 10 seconds is not always enough). David, this has been tested on FreeBSD 7.4 (so far) and is essential for the buildbot client tests :-) - more platform tests will follow as soon as I have all the server stanzas up and running. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

On Thursday 17 May 2012 19:06:06 Yi-Wen Cheng wrote: > I just finished both of files for translating to traditional chinese. Took me a little while, but I just finished integrating it into the GUI. Don't know what .lang file is for, but I suppose it's another project you contribute translation to. The .rc file is now part of the official OpenVPN-GUI. Thanks for your efforts! > Btw,how can I see the new GUI of traditional chinese on my laptop? I released a new snapshot binary. You should be able to download it once it's spread across the Sourceforge download mirrors at http://sf.net/projects/openvpn-gui/files/Snapshot%20Binaries/2012-05-22/ Will you do the translation to Simplified Chinese as well? Is so, please base it on the openvpn-gui-res-zh-hant.rc file in the repository. I made some changes to the one you sent. Thanks again Heiko -- Heiko Hund | Software Engineer | Tel +49-721-25516-237 | Fax -200 SOPHOS NSG | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany 

Looks good! I'll give it a feature ack. I don't see any problems in the autoconf code, but I'm not an expert in that area. So a tentative ack there too. Adriaan > -----Original Message----- > From: Alon Bar-Lev [mailto:alo...@gm...] > Sent: maandag 21 mei 2012 13:04 > To: ope...@li... > Cc: Alon Bar-Lev > Subject: [Openvpn-devel] [PATCH] build: check minimum polarssl version > > Pre 1.1 is unsupported, API was changed. > > Signed-off-by: Alon Bar-Lev <alo...@gm...> > --- > configure.ac | 21 +++++++++++++++++++++ > 1 files changed, 21 insertions(+), 0 deletions(-) > > diff --git a/configure.ac b/configure.ac index 4592727..5ace128 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -743,6 +743,27 @@ if test -z "${POLARSSL_LIBS}"; then >	) > fi > > +if test "${with_crypto_library}" = "polarssl" ; then > +	AC_MSG_CHECKING([polarssl version]) > +	old_CFLAGS="${CFLAGS}" > +	CFLAGS="${POLARSSL_CFLAGS} ${CFLAGS}" > +	AC_COMPILE_IFELSE( > +	[AC_LANG_PROGRAM( > +	[[ > +#include <polarssl/version.h> > +	]], > +	[[ > +#if POLARSSL_VERSION_NUMBER <= 0x01010000 #error invalid version > #endif > +	]] > +	)], > +	[AC_MSG_RESULT([ok])], > +	[AC_MSG_ERROR([invalid polarssl version])] > +	) > +	CFLAGS="${old_CFLAGS}" > +fi > + > AC_ARG_VAR([LZO_CFLAGS], [C compiler flags for lzo]) > AC_ARG_VAR([LZO_LIBS], [linker flags for lzo]) have_lzo="yes" > -- > 1.7.3.4 > > > ----------------------------------------------------------------------- > ------- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions > will include endpoint security, mobile security and the latest in > malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel 

Pre 1.1 is unsupported, API was changed. Signed-off-by: Alon Bar-Lev <alo...@gm...> --- configure.ac | 21 +++++++++++++++++++++ 1 files changed, 21 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 4592727..5ace128 100644 --- a/configure.ac +++ b/configure.ac @@ -743,6 +743,27 @@ if test -z "${POLARSSL_LIBS}"; then	) fi +if test "${with_crypto_library}" = "polarssl" ; then +	AC_MSG_CHECKING([polarssl version]) +	old_CFLAGS="${CFLAGS}" +	CFLAGS="${POLARSSL_CFLAGS} ${CFLAGS}" +	AC_COMPILE_IFELSE( +	[AC_LANG_PROGRAM( +	[[ +#include <polarssl/version.h> +	]], +	[[ +#if POLARSSL_VERSION_NUMBER <= 0x01010000 +#error invalid version +#endif +	]] +	)], +	[AC_MSG_RESULT([ok])], +	[AC_MSG_ERROR([invalid polarssl version])] +	) +	CFLAGS="${old_CFLAGS}" +fi + AC_ARG_VAR([LZO_CFLAGS], [C compiler flags for lzo]) AC_ARG_VAR([LZO_LIBS], [linker flags for lzo]) have_lzo="yes" -- 1.7.3.4 

# this is a language file for Vistalizator # compatible versions: 2.30 # author: froggie # save this file in Unicode or UTF to preserve special characters # put this file into program's "Languages" subfolder to have it loaded automatically at program's startup # (it will be silently skipped if there is a built-in language with the same "EnglishName" value in its header) # after approval, this translation can become a new buit-in language amongst others and will be included in a pack of all languages available for download # English is a fallback language for missing lines (built in program) # "|" represents a newline character (only messages 043, 084-096, 100 and 600-800: otherwise it is ignored as not expected/allowed), e.g. "Line1.|Line2.|Line3." # leading/trailing spaces are trimmed: e.g. "001 = System configuration" is the same as "001=System configuration" # use quotes to keep leading/trailing spaces in the message: e.g. 081=" or " # put "" instead of a translated message if you want to get a blank message, e.g. 123="" # some messages are limited in length to prevent caption overflow of that particular GUI component # %1, %2, %3 and %4 represent a dynamic parameter (should not be omitted) resolved at runtime, e.g. "175=Installing Windows Vista update: %1..." # additionally, languages' names can have multiple forms, e.g. in German: "300=Dänisch; dänisch; dänischer; dänische; dänisches" # there can be up to 9 forms, the specific one can be chosen like this: e.g. "240=Loading %1#3 language pack." or "Current LIP language: %1#4 on %2#2." [Header] # the following 2 lines are mandatory, "EnglishName" value must be unique, it is case insensitive EnglishName=Chinese (Traditional) NativeName=中文（繁體） # set True if applicable (Arabic, Hebrew and similar languages), can be omitted=False RightToLeft=False [Main window] 001=系統配置 002=已安裝的語言 003=系統： 004=原始語言： 005=現行語言： 006=新語言： 007=退出 008=關於 009=幫助 010=添加語言 011=更改語言 012=移動語言 013=更新語言 014=語言 015=類型 016=模式 017=內部 018=快速 019=未定 # a legend below the table of installed languages 020=依靠 MUI* 的 LIP 語言已安裝 # "Current Language" label value # e.g. "Spanish (should be upgraded to SP1)" 021=%1 (應該更新到 SP%2) # e.g. "Catalan： on Spanish" 022=%1：使用%2 # e.g. "Spanish" 023=%1 # "New Language" label value # e.g. "Spanish (should be upgraded to SP1)" 024=%1 (應該更新到 SP%2) # e.g. "Catalan： on Spanish" 025=%1：使用%2 # e.g. "Spanish" 026=%1 # "Original Language" label value, always MUI # e.g. "Spanish" 027=%1 # a language name in the table of installed languages (main window) # e.g. "Spanish" 028=%1 [Program's menu] 030=語言 031=幫助 032=添加... 033=輸出所有... 034=顯示幫助 035=關於 Vistalizator [About dialog] 040=關於 Vistalizator 041=Windows Vista 和 Windows 7 定位工具 042=Copyright © 2008-2010 by froggie # 1 newline character can be used 043=如果您發現本工具值得捐款 044=請單擊捐款 [Help dialog] # window title 050=幫助内容 [Parent languages dialog] # e.g. "Choose parent language for Catalan" 051=選擇%1的父語言 052=可用的語言 # OK button 053=確定 # Cancel button 054=取消 # a parent language name： caption of a checkbox # e.g. "Spanish" 055=%1 [Dialog with language packs loaded] 060=安裝語言 061=安裝語言 062=取消安裝過程 063=寂靜安裝 064=* 單擊單元更改安裝模式或(取消)選擇安裝的語言 065=* 單擊單元(取消)選擇安裝的語言 066=MUI 語言包： 提供所有界面的翻譯 067=LIP 語言包： 提供普通界面的翻譯，需要 MUI 父語言 068=快速模式： 使用本程序的安裝程序裝語言。 # Windows Vista 32-bit 069=内部模式 (測試於 MUI)： 使用 Windows 内部安裝程序裝語言。 # Windows 7 070=内部模式： 使用 Windows 内部安裝程序裝語言。 # Windows Vista 64-bit 071=内部模式 (不可用)： 使用 Windows 内部安裝程序裝語言。 072=語言包已加載： 沒有選擇安裝 # e.g. "Spanish language pack loaded： not selected for installation" 073=%1語言包已加載： 沒有選擇安裝 # "Spanish language pack loaded： selected for installation" 074=%1語言包已加載： 已選擇安裝 # e.g. "Language packs loaded, selected for installation： 5" 075=語言包已加載，已選擇安裝： %1 # a language name in the table of loaded languages (window with language packs loaded) # e.g. "Spanish" 076=%1 077=安裝 078=是 079=否 # line delimiter, e.g. "French|and|Spanish" 080=和 # word delimiter, e.g. "French or Spanish"; quotes used to keep leading/trailing spaces (won't be used) 081="或" # line delimiter, e.g. "French|or|Spanish" 082=或 # e.g. "Catalan language cannot be installed using Internal mode. To install it the following must be met：" 084=%1不可使用内部模式安裝。需要安裝，您必需满足下列要求： # e.g. "Spanish parent language is the current display language." 085=%1父語言是現行顯示語言。 # e.g. "One of these parent languages is the current display language： French or Spanish." # a newline character can be used, %1 is a list of languages separated by message #081 (" or ") 086=其中一種父語言是現行的顯示語言： %1。 # e.g. "Spanish parent language has been installed in Internal mode and is the current display language." 087=已經在内部模式中安裝%1父語言，本語言是現行的顯示語言。 # e.g. "One of these parent languages has been installed in Internal mode and is the current display language： French or Spanish." # a newline character can be used, %1 is a list of languages separated by message #081 (" or ") 088=已經在内部模式中安裝其中的父語言，本語言是現行的顯示語言： %1。 # 32-bit Windows Vista 089=MUI 語言的内部安裝模式使用Windows的安裝程序，只能在您的系统中運行一次！|為了在本模式中安裝多 MUI 語言種類，需要加載盡可能多的MUI語言，然後更改模式到内部。|請注意，LIP語言沒有本限制，但如果要使用内部模式中安裝LIP語言，您需要先安裝MUI父語言。 # 64-bit Windows Vista 090=MUI 語言的内部安裝模式使用Windows的安裝程序，只能在您的系统中運行一次！|為了在本模式中安裝多 MUI 語言種類，需要加載盡可能多的MUI語言，然後更改模式到内部。 # e.g. "Catalan LIP language will use Spanish as the parent language." 091=%1 LIP 語言需要用%2為父語言。 # e.g. "Catalan LIP language uses Spanish as the parent language, but it is not selected for installation." 092=%1 LIP 語言需要用%2為父語言，但沒有選擇安裝。 # e.g. "Catalan LIP language can use these parent languages： French or Spanish." # a newline character can be used, %2 is a list of languages separated by message #081 (" or ") 093=%1 LIP 語言可以使用這些父語言： %2。 # e.g. "Catalan LIP language can use these parent languages： French or Spanish, but it is not selected for installation." # a newline character can be used, %2 is a list of languages separated by message #081 (" or ") 094=%1 LIP 語言可以使用這些父語言： %2，但沒有選擇安裝。 # e.g. "Spanish language will be upgraded to be Windows Vista SP1 compatible." 095=%1會被更新為%2 SP%3兼容。 096=%1沒有選擇更新到%2 SP%3。 # LIP language as part of a list, e.g. "Basque, Catalan and Luxembourgish", items separated by message #098 and #099 097=%1 # a separator to a list of LIP languages (e.g. "Basque, Catalan and Luxembourgish"); quotes used to keep leading/trailing spaces (won't be used) 098="、" # a separator to a list of LIP languages (e.g. "Basque, Catalan and Luxembourgish"); quotes used to keep leading/trailing spaces (won't be used) # for the last item 099="和" # e.g. "Upon installing Spanish MUI, LIP languages requiring this parent language can be installed：" 100=安裝%1 MUI时，可以安裝需要本父語言的LIP語言： 101=選擇安裝%1 102=沒有選擇安裝%1 # tooltip message for "Silent installation" checkbox 103=After completing the installation, user is not asked to change to the new language (batch mode). [Button "Add languages" FileOpen dialog] # FileOpen dialog title 120=打開Windows語言包 # file extension filter # e.g. "langpacks (*.exe, *.cab, *.mlc)", 32-bit Windows 121=語言包 # e.g. "language packs (*.exe, *.cab)", 64-bit Windows 122=語言包 # e.g. "MUI language packs (*.exe)" or "MUI language packs (*.cab)" 123=MUI 語言包 # e.g. "LIP language packs (*.mlc)" 124=LIP 語言包 [Button "Update languages" FileOpen dialog] # FileOpen dialog title 125=打開Windows update文件 # e.g. "Windows updates (*.msu, *.exe)" 126=Windows updates [Menu->Languages->Add... FileOpen dialog] # FileOpen dialog title 127=打開本程序的語言文件 # e.g. "language files (*.lang)" 128=語言文件 # e.g. "all files (*.*)" 129=所有文件 [Menu->Languages->Export All... SelectFolder dialog] 130=選擇保存語言的文件夾 [Statusbar messages] # e.g. "Press Add languages and open Windows language pack(s). Download links can be found in Help." # %1 = message #010 ("Add languages") 150=按 %1 然後打開Windows語言包。幫助有下載鏈接。 151=正在退出程序... # e.g. "Loading language pack： lp_en-us.exe" 152=正在加載語言包： %1 # e.g. "Loading language pack 2 of 3： lp_en-us.exe" 153=正在加載語言包 %1 共 %2： %3 # e.g. "Language pack loaded： English" 154=語言包已加載： %1 155=沒有加載語言包。請再試一次。 # e.g. "Number of language packs loaded： 3" 156=已加載的語言包的數量： %1 # e.g. "Express installation： Installing Spanish language..." 157=快速安裝： 正在安裝%1... # e.g. "Express installation： Upgrading Spanish language..." 158=快速安裝： 正在更新%1... # e.g. "Express installation： Processing language 1 of 3..." 159=快速安裝： 正在處理語言 %1 共 %2... 160=解壓語言包錯誤！請再試一次。 # e.g "Spanish language was not installed correctly. Please contact author to get help." 161=沒有正確地安裝%1。請與作者聯繫，尋求幫助。 # e.g. "Spanish language was installed successfully." 162=%1已成功安裝。 # e.g. "Spanish language was upgraded successfully to SP1." 163=%1已成功更新到 SP1。 164=%1已成功更新到 SP2。 165=%1已成功更新到 SP3。 # e.g "Display language was changed to： Spanish." 166=顯示語言已更改為： %1。 # e.g "Display language was changed to： Catalan. Its parent language was set to： Spanish." 167=顯示語言已更改為： %1。父語言已定為： %2. # e.g. "Display language reverted to current language： Spanish." 168=顯示語言已回復到現行語言： %1。 # e.g. "Spanish language was added to the list of installed languages." 169=%1已添加到安裝語言的目錄。 # e.g. "Internal installation： Installing Spanish language..." 170=内部安裝： 正在安裝%1... # e.g. "Internal installation： Installing 3 languages..." 171=内部安裝： 正在安裝%1種語言... 172=用户取消内部安裝過程。 173=内部安裝失敗。 174=所有語言已成功安裝 # e.g "Installing Windows Vista update： KB123456..." 175=正在安裝 Windows Vista 更新： %1... 176=解壓更新文件錯誤！ 請再試一次。 # e.g. "Windows Vista update "KB940157" was installed successfully." 177=Windows Vista "%1" 更新已成功安裝。 # e.g. "Installing Windows update： Windows Update Agent v123..." 178=正在安裝 Windows update： %1... # e.g. "Windows update "Windows Update Agent v123" was installed successfully." 179=Windows update "%1" 已成功安裝。 # e.g "Installing Windows 7 update： KB123456..." 180=正在安裝 Windows 7 更新： %1... # e.g. "Windows 7 update "KB123456" was installed successfully." 181=Windows 7 "%1" 更新已成功安裝 # e.g. "Removing Spanish language..." 182=正在移動%1... # e.g. "Uninstalling English language..." 183=正在卸載%1... 184=卸載失敗。 # e.g. "English language was uninstalled successfully." 185=%1已成功卸載。 # e.g. "English language was removed successfully." 186=%1已成功移動。 # e.g. "Spanish language was uninstalled. Display language reverted to current language： English." 187=%1已成功卸載。顯示語言已回復為現行語言： %2。 # e.g. "Spanish language was removed. Display language reverted to current language： English." 188=%1已移動。顯示語言已回復為現行語言： %2。 189=正在檢測重要的更新... # e.g."Loading Windows Vista update： KB123456.msu" 190=正在加載 Windows Vista 更新： %1 # e.g."Loading Windows 7 update： KB123456.msu" 191=正在加載 Windows 7 更新： %1 # e.g. "Languages need to be upgraded to SP1 before installing Windows update： KB123456." 192=需要更新語言到 SP%1，才能安裝 Windows update： %2。 193=需要更新語言到 SP%1，才能安裝 “Windows Update Agent”。 194=用户取消 Windows update 的安裝過程 195=用户取消 Windows Update 的安裝過程 # e.g. "Loading program's language file： Spanish.lang" 196=正在加載程序的語言包： %1 [Progress dialog] # e.g. "Loading Spanish language pack" 240=正在加載%1語言包 241=正在確認文件的完整性... # e.g. "Express installation： Installing Spanish" 242=快速安裝： 正在安裝%1 # e.g. "Express installation： Spanish is being upgraded to SP1" 243=快速安裝： 正在更新%1至 SP1 244=快速安裝： 正在更新%1至 SP2 245=快速安裝： 正在更新%1至 SP3 # e.g. "Internal installation： Installing Spanish" 246=内部安裝： 正在安裝%1 # e.g. "Internal installation： Installing 3 languages" 247=内部安裝： 正在安裝%1種語言 248=正在擴大語言包... (過程 1/4) 249=正在解壓語言包... (過程 2/4) 250=正在删除臨時文件... (過程 3/4) 251=正在更新註冊表設定... (過程 4/4) 252=正在準備内部安裝 253=請稍候... # e.g. "This may take up to 30 minutes, please wait..." 254=本過程可能佔用約%1分钟的时间，請稍候... 255=正在安裝 Windows Vista 更新 256=這個在加載文件... # e.g. "Updating Spanish language..." 257=正在更新%1... 258=正在删除臨時文件... 259=正在安裝 Windows 7 更新 # e.g. "Removing Spanish" 260=正在移動%1 261=正在删除語言包... # e.g. "Uninstalling Spanish" 262=正在卸載%1 263=正在加載 Windows 語言包 264=正在轉換文件... [Windows Vista MUI languages] # different forms of a particular language (leading/trailing spaces are ignored), separated by ";" # e.g. in German: "300=Dänisch; dänisch; dänischer; dänische; dänisches" # there can be up to 9 forms, the specific form can be chosen like this: e.g. "240=Loading %1#2 language pack" # if not specified or non-existent the first form is used: i.e. "240=Loading %1 language pack" 300=丹麥語 301=德語 302=英語 303=西班牙語 304=芬蘭語 305=法語 306=意大利語 307=日語 308=韓國語 309=挪威語 310=荷蘭語 311=葡萄牙語 (巴西) 312=俄語 313=瑞典語 314=中文 (簡体) 315=中文 (繁体) 316=阿拉伯語 317=保加利亞語 318=捷克語 319=希臘語 320=爱沙尼亞語 321=希伯來語 322=克羅地亞語 323=匈牙利語 324=立陶宛語 325=拉脱维亞語 326=波瀾語 327=葡萄牙語 (葡萄牙) 328=羅馬尼亞語 329=斯洛伐克語 330=斯洛文尼亞語 331=塞爾维亞語 (拉丁語) 332=泰語 333=土耳其語 334=烏克蘭語 335=中文 (臺灣) [Windows Vista LIP languages] 350=阿薩姆語 351=孟加拉語 352=波斯尼亞語（西里爾） 353=波斯尼亞（拉丁） 354=加泰罗尼亞語 355=威爾士 356=巴斯克 357=加利西亞語 358=古吉拉特語 359=印地語 360=印尼語 361=冰島語 362=哈撒克語 363=坎納達語 364=孔卡尼語 365=吉爾吉斯語 366=馬其頓語 367=馬來亞語 368=馬拉語 369=馬來語 370=挪威文（耐諾斯克挪威語） 371=奧里雅語 372=旁遮普語 373=阿爾巴尼亞語 374=塞爾维亞語（西里爾） 375=泰米爾語 376=韃靼語 377=烏茲别克語（拉丁） 378=越南語 379=因纽特語 380=馬來語（文莱） 381=泰卢固語 382=格鲁吉亞語 383=阿塞拜疆語 384=亞美尼亞 385=南非荷兰語 386=塞索托語 387=科萨語 388=祖鲁語 389=卢森堡語 390=菲律宾語 391=孟加拉語（孟加拉国） 392=塞兹瓦纳語 393=老挝語 394=高棉語 395=波斯語 396=伊博語 397=约鲁巴語 398=豪萨語（拉丁） 399=马耳他語 400=僧伽罗語 401=Maori 402=Urdu 403=Nepali 404=Quechua [Windows 7 MUI languages] 450=丹麦語 451=德語 452=英語 453=西班牙語 454=芬兰語 455=法語 456=意大利語 457=日語 458=韩国語 459=挪威語 460=荷兰語 461=葡萄牙語 (巴西) 462=俄語 463=瑞典語 464=中文 (简体) 465=中文 (繁体) 466=阿拉伯語 467=保加利亞語 468=捷克語 469=希腊語 470=爱沙尼亞語 471=希伯来語 472=克罗地亞語 473=匈牙利語 474=立陶宛語 475=拉脱维亞語 476=波兰語 477=葡萄牙語 (葡萄牙) 478=罗马尼亞語 479=斯洛伐克語 480=斯洛文尼亞語 481=塞爾维亞語 (拉丁語) 482=泰語 483=土耳其語 484=乌克兰語 485=中文 (台湾) [Windows 7 LIP languages] 500=印地語 501=加泰罗尼亞語 502=塞爾维亞語（西里爾） 503=冰岛語 504=威爾士 505=越南語 506=挪威文（耐諾斯克挪威語） 507=波斯語 508=巴斯克 509=加利西亞語 510=古吉拉特語 511=阿萨姆與 512=印尼語 513=哈撒克語 514=坎納達語 515=馬來亞語 516=馬拉語 517=奧里雅語 518=阿爾巴尼亞語 519=泰米爾語 520=泰卢固語 [Information/warning/error messages in a system dialog] 600=命令行参數：||/？ - 幫助窗口|/h - 幫助窗口|/c - 在程序的文件夾中保存語言組態|/p - 顯示内部安裝過程 601=應用變化需要註銷。|繼續之前，請您保存所有的工作！ 602=應用變化需要重新起動您的系统。|繼續之前，請您保存所有的工作！ 603=這不是 Windows 的語言包! 604=64-bit Windows 不支持 LIP 語言包。 605=文件類型錯誤! 請使用其它文件。 606=加載語言包錯誤!||請確認語言包已經成功下載：|使用 MD5 檢查器檢查他的完整性。 607=無法識别的語言區域設置： 不支持本語言或文件已損壞。|請使用 Vistalizator 的最新版本或打開另一個文件。 608=本語言包不可用於 Windows Vista 或 Windows 7。 609=本語言包只能用於 Windows Vista。|您用的是 Windows 7 操作系统。 610=本語言包只能用於 Windows 7。|您用的是 Windows Vista 操作系统。 611=不是 Windows 語言包! 請使用另一個文件。 # e.g. "To install Catalan language one of the required parent MUI languages must be installed first：|Spanish or French" # %2 is a list of languages separated by message #081 (" or ") 612=安裝%1需要先安裝其中一種 MUI 父語言：|%2 # e.g. "To install Albanian language the required parent MUI language must be installed first： English." 613=安裝%1需要先安裝 MUI 父語言： %2. # e.g. "This language pack is for 32-bit Windows Vista only.|You have a 64-bit operating system." 614=本語言包僅能用於 32-bit %1。|您擁有的是 64-bit 操作系统。 615=本語言包僅能用於 64-bit %1。|您擁有的是 32-bit 操作系统。 616=此語言包僅與 Windows Vista RTM 兼容。|您擁有的是包含 SP1 的 Windows Vista。 617=此語言包僅與 Windows Vista RTM 兼容。|您擁有的是包含 SP2 的 Windows Vista。 618=此語言包僅與 Windows Vista RTM 兼容。|您擁有的是包含 SP3 的 Windows Vista。 619=此語言包與 Windows Vista RTM 或 SP1 兼容。|您擁有的是包含 SP2 的 Windows Vista。 620=此語言包與 Windows Vista RTM 或 SP1 兼容。|您擁有的是包含 SP3 的 Windows Vista。 621=此語言包與 Windows Vista RTM、SP1 或 SP2 兼容。|您擁有的是包含 SP3 的 Windows Vista。 622=此語言包僅與 Windows 7 RTM 兼容。|您擁有的是包含 SP1 的 Windows 7。 623=此語言包僅與 Windows 7 RTM 兼容。|您擁有的是包含 SP2 的 Windows 7。 624=此語言包僅與 Windows 7 RTM 兼容。|您擁有的是包含 SP3 的 Windows 7。 625=此語言包與 Windows 7 RTM 或 SP1 兼容。|您擁有的是包含 SP2 的 Windows 7。 626=此語言包與 Windows 7 RTM 或 SP1 兼容。|您擁有的是包含 SP3 的 Windows 7。 627=此語言包與 Windows 7 RTM、SP1 或 SP2 兼容。|您擁有的是包含 SP3 的 Windows 7。 # e.g. "Spanish language is already installed.|Please try another one." 628=%1已安裝。|請再試别的語言。 # e.g. "Spanish language is already installed.|Skipping..." 629=%1已安裝。|省略中... # e.g. "Spanish was installed on Windows Vista RTM. You should upgrade it to SP1, but it is currently used.|Please change to another language, restart Windows and try again." # %2 can be "Windows Vista" or "Windows 7", %3 can be RTM/SP1/SP2, %3 can be RTM/SP1/SP2/SP3 630=%1已安裝在%2 %3上。您應該更新至%4，可文件正在被利用中。|請更換另外一種語言、重新啟動Windows，然後再試一次。 # e.g. "Spanish was installed on Windows 7 SP1. Do you want to upgrade it to be SP2 compatible？" 631=%1已安裝在%2 %3上。您要更新到與%4兼容的版本吗？ # e.g. "You should upgrade SPanish language to SP1 as soon as possible." 632=您應該盡快更新%1至%2。 # e.g. Spanish language pack is already loaded.|Skipping... 633=已經加載%1的語言包。省略中... 634=錯誤： 更新Windows註冊表失敗! # e.g. "Done! Do you want to make Spanish language the new display language？" 635=成功! 您需要更改顯示語言為%1吗？ # e.g. "Spanish should be upgraded to SP1." 636=應該更新%1至SP1。 637=應該更新%1至SP2。 638=應該更新%1至SP3。 639=退出程序註銷，使更改生效。 # e.g. "You may need to update the new language：|Press the Update languages button to finalize the installation.||Then exit program to restart the system for the changes to take effect." # %1 = message #013 ("Update languages") 640=您可能要更新新語言種類：|單擊 %1 按鈕完成安裝。||然後退出程序重新啟動系统，以使更改生效。 # e.g. "You can find Spanish language in the list of installed languages. Select it and press the Change language button to activate it.||Always check that Windows Update is functioning after starting to use the new language! See details in Help." # %2 = message #011 ("Change language") 641=您可以在已安裝語言的表格上發現%1。需要激活本語言，選取語言然後單擊 %2 按鈕。||請随时檢查Windows Update在安裝新語言之後，是否正常運行！請阅讀幫助文件了解详细信息。 642=内部安裝失敗! 由於本功能為試用功能，成功是無法保证的。您可以用快速安裝模式。 643=内部安裝失敗! 由於本功能為試用功能，成功是無法保证的。您可以用快速安裝模式。|或许，您可以重新使用 /p 参數運行 Vistalizator查看關於安裝過程或任何錯誤的信息。 644=退出程序重新啟動系统，以使更改生效。 # e.g. "You may need to update the new language：|Press the Update languages button to finalize the installation." # %1 = message #013 ("Update languages") 645=您可能需要更新新語言：|單擊 %1 按鈕完成安裝。 646=您可能需要更新新語言：|單擊 %1 按鈕完成安裝。 647=加載文件錯誤!||請確認所有Windows更新文件已完整下載：|用 MD5 檢查器確認文件完整性。 # e.g. This language has been installed before installing Service Pack 2 for Windows Vista.|It can be used but should be upgraded to SP2 as soon as possible. You can do this by installing SP2 Spanish language pack.||Do you really want to change language？ 648=本語言是在安裝%2的Service Pack %1之前所安裝的。|語言还可以使用，可應該盡快更改至SP%1。您可以通過安裝 SP%1 %3語言包来更新語言。||您是否確定您要更改語言？ # e.g. "Spanish should be upgraded to SP1." 649=應該更新%1至SP1。 650=應該更新%1至SP2。 651=應該更新%1至SP3。 # e.g. "Ooops, cannot find any parent language for Catalan!|Install French or Spanish first to be able to change display language to Catalan." # %2 is a list of languages separated by message #081 (" or ") if more than 1 language is applicaple 652=找不到任何%1的父語言！|安裝%2以能够更改顯示語言為%1。 [Message dialogs： Update languages Button] 653=沒有在快速模式中安裝的MUI語言：|沒有需要安裝的Windows update。 654=沒有需要安裝的Windows update。 # e.g. "The current version of your Windows Update Agent (6.0.6000.16386) is not supported..." 655=不支持您的 Windows Update Agent (%1) 的版本。請確認您有最新的Vistalizator。|如果您的版本是最新的，並遇到錯誤，請與作者聯繫。 656=不能驗證您的Windows Update Agent (%1)的版本。請確認您有最新的Vistalizator。|如果您的版本是最新的，並遇到錯誤，請與作者聯繫。 # %1 is e.g. Windows Udate Agent v123|Windows Search 4.0 657=沒有需要安裝的Windows update。|現在支持這些更新：||%1 658=沒有需要安裝的Windows update。|現在支持這些更新：||%1 659=需要安裝此Windows update：|(下載鏈接在幫助文件中)||%1 660=需要安裝此Windows update：|(下載鏈接在幫助文件中)||%1 661=不受支持的文件格式 (需要 EXE 或 MSU)! 請試用其它文件。 662=檔案標題讀取錯誤!不是Windows update或者不支持此文件。|請試用其它文件。 663=包裝讀取錯誤!|確認文件已完整下載。 664=無法識别Windows update的結構 (32位/64位)。 665=此更新僅適用於Windows Vista。|您擁有的是Windows 7操作系统。 666=此更新僅適用於Windows 7。|您擁有的是Windows Vista操作系统。 667=此更新僅適用於32位Windows Vista。|您擁有的是64位操作系统。 668=此更新僅適用於64位Windows Vista。|您擁有的是32位操作系统。 669=此更新僅適用於32位Windows 7。|您擁有的是64位操作系统。 670=此更新僅適用於64位Windows 7。|您擁有的是32位操作系统。 671=不是Windows update或者不支持此文件!|請試用其它文件。 672=Windows update文件處理錯誤：無法識别的版本 673=不支持本Windows update。|很可能不需要安裝。 # e.g. "Integrity validation failed for 32-bit Windows update： KB123456.|Make sure the file downloaded properly." 674=32位Windows update的完整性驗證失敗： %1。|確認文件已完整下載 675=64位Windows update的完整性驗證失敗： %1。|確認文件已完整下載 # e.g. "Spanish" 676=由於系统在使用一些文件，無法更新現行語言(%1)。|請更改語言、重新啟動Windows然後再試一次。 677=由於系统在使用一些文件，無法更新現行語言(%1)。處理過程將跳過此語言...|請更改語言、重新啟動Windows然後再試一次。 # e.g. "Parent language (Spanish) of the current language (Catalan) cannot be updated..." 678=由於系统在使用一些文件，無法更新現行語言(%2)的父語言(%1)|請更改語言、重新啟動Windows然後再試一次。 679=由於系统在使用一些文件，無法更新現行語言(%2)的父語言(%1)。處理過程將跳過此語言...|請更改語言、重新啟動Windows然後再試一次。 # e.g. "Windows update KB123456 doesn't need to be applied to any language." 680=Windows update %1對任何語言沒有效應。 # MUI language as part of a list, e.g. "Spanish" or "French, Spanish", items separated by message #682 (", ") 681=%1 # a separator to a list of languages (e.g. "French, Spanish, German"); quotes used to keep leading/trailing spaces (won't be used) 682="、" # e.g. "KB940157 (Windows Search 4.0) for languages：" or "Windows Update Agent (v7.2.6001.788) for languages：" # a list of languages follows (an item form specified by message #681) after the sentence, separated by message #682 (", ") if there are too many items (on separate lines otherwise) 683=適用於這些語言的%1 (%2)： # e.g. "Windows update KB123456 can be applied to the following language after its upgrade to SP1： Spanish." 684=Windows update %1更新到SP%2後可以應用於這些語言： %3。 # a list of languages follows (an item form specified by message #681) after the sentence, separated by message #682 (", ") if there are too many items (on separate lines otherwise) 685=Windows update %1更新到SP%2後可以應用於下列語言：|| # e.g. "Windows update KB123456 will be applied to the following language： Spanish." 686=Windows update %1將應用於這些語言： %2。 # a list of languages follows (an item form specified by message #681) after the sentence, separated by message #682 (", ") if there are too many items (on separate lines otherwise) 687=Windows update %1 將應用於下列語言：|| 688=這不是Windows Update Agent安裝程序或不支持本文件。|請使用其它文件。 689=加載文件中遇到内部錯誤。 # e.g. "This version (7.3.6002.123) of Windows Update Agent is not supported." 690=不支持Windows Update Agent的此版本(%1)。 # e.g. "Integrity validation failed for： Windows Update Agent v7.2.6001.788 for 32-bit Windows.|Make sure the file downloaded properly." 691=完整性驗證失敗在於： 適用於32位Windows的Windows Update Agent v%1。|請確認文件已完整下載。 692=完整性驗證失敗在於： 適用於64位Windows的Windows Update Agent v%1。|請確認文件已完整下載。 # e.g. "This version of Windows Update Agent (v7.3.6002.123) differs from that required： 7.2.6001.788." 693=Windows Update Agent (v%1) 的版本與需要的版本有所不同： %2. 694=Windows Update Agent (v%1) 的版本與需要的版本有所不同 # e.g. "Windows Update Agent v7.2.6001.788 doesn't need to be applied to any language." 695=Windows Update Agent v%1對任何語言沒有效應。 # e.g. "Windows Update Agent v7.2.6001.788 can be applied to the following language after its upgrade to SP1： Spanish." 696=Windows Update Agent v%1更新到SP%2後可以應用於這些語言： %3。 # a list of languages follows (an item form specified by message #681) after the sentence, separated by message #682 (", ") if there are too many items (on separate lines otherwise) 697=Windows Update Agent v%1更新到SP%2後可以應用於下列語言：|| # e.g. "Windows Update Agent v7.2.6001.788 will be applied to the following language： Spanish." 698=Windows Update Agent v%1將應用於這些語言： %2。 # a list of languages follows (an item form specified by message #681) after the sentence, separated by message #682 (", ") if there are too many items (on separate lines otherwise) 699=Windows Update Agent v%1將應用於下列語言：|| [Message dialogs： Remove language Button] # "Catalan： no alternative parent language" 700=%1：沒有供選擇的父語言 # MUI language as part of a list, e.g. "(not installed) Spanish" or "(not installed) French or (not installed) Spanish", the list is then a supplement of message #703 701=（沒安裝）%1 # MUI language as part of a list, e.g. "Spanish" or "French or Spanish", the list is then a supplement of message #703 702=%1 # e.g. "Catalan： (not installed) French or (not installed) Spanish" or "Catalan： French or Spanish" # %2 can be message #701 and/or #702 703=%1： %2 # e.g. "Spanish can be removed as the dependent Catalan language can use French as an alternative parent language." 704=可以移動%1，因為有關的%2可以用%3為供選的父語言。 # e.g. "Croatian can be removed as the dependent Bosnian (latin) language can use English or Serbian (latin) as alternative parent languages." 705=可以移動%1，因為有關的%2可以用%3為供選的父語言。 # e.g. "English can be removed as all dependent LIP languages can use other installed languages as alternative parent languages：||" # "Azeri： Russian" # "Luxembourgish： French" # "Bosnian (cyrillic)： Croatian or Serbian (latin)" 706=可以移動%1，因為有關的LIP語言可以用其他已安裝的語言為供選語言：||%2 # e.g. "Spanish cannot be removed as there is a dependent LIP language installed：||Catalan： (not installed) French||First remove this LIP language or install its alternative parent language(s) and then try again." 707=不可以移動%1，因為有其它已安裝的有關的LIP語言：||%2||首先要移動此LIP語言或安裝其它父語言，然後再試一次。 # e.g. "English cannot be removed as the dependent Albanian language can't use another alternative parent language.||Remove this LIP language first and try again." 708=不可以移動%1，因為有關的%2不能用其它的父語言。||首先要移動此LIP語言，然後再試一次。 # e.g. "English cannot be removed as there are dependent LIP languages without an alternative parent language：|| # "Albanian： no alternative parent language" # "Azeri： (not installed) Russian" # "First remove all LIP languages without an alternative parent language and/or install alternative parent languages and then try again." 709=不可以移動%1，因為有關的LIP沒有其它可選的父語言：||%2||首先要移動此LIP語言或安裝其它父語言，然後再試一次。 # e.g. "English cannot be removed as there are dependent LIP languages without an alternative parent language：|| # "Albanian： no alternative parent language" # "Armenian： no alternative parent language" # "First remove all LIP languages and then try again." 710=不可以移動%1，因為有關的LIP沒有其它可選的父語言：||%2||首先要移動此LIP語言，然後再試一次。 # e.g. "English is the parent language of the new display language： Albanian.|Removing it will revert the display language back to current language： Catalan on Spanish." 711=%1是新顯示語言的父語言： %2。|移動語言會回復顯示語言到此語言：%4上的%3。 # e.g. "English is the parent language of the new display language： Albanian.|Removing it will revert the display language back to current language： Spanish." 712=%1是新顯示語言的父語言： %2。|移動語言會回復顯示語言到此語言：%3。 # e.g "Do you really want to uninstall English language？" # applies to Internal languages： will be uninstalled by Windows installer 713=您是否確定需要移動%1？ # applies to Express languages： will be removed by Vistalizator 714=您是否確定需要移動%1？ # e.g. "Do you really want to uninstall Spanish language？|Uninstalling it will revert the display language back to current language： Catalan on Spanish." 715=您是否確定需要移動%1？|移動語言會回復顯示語言到此語言：%3上的%2。 716=您是否確定需要移動%1？|移動語言會回復顯示語言到此語言：%3上的%2。 # e.g. "Do you really want to uninstall Spanish language?|Uninstalling it will revert the display language back to current language: English." 717=您是否確定需要移動%1？|移動語言會回復顯示語言到此語言： %2。 718=您是否確定需要移動%1？|移動語言會回復顯示語言到此語言： %2。 719=卸載失敗! 720=您可能要重新啟動系统，完成卸載過程。 721=請注意，Windows不會更新在快速模式中安裝的MUI語言。查看幫助文件了解使用Vistalizator更新語言的方法。|虽然是實驗用的MUI語言的功能，您應該先試用内部安裝 # e.g. "Not enough free space on disk C： for temporary data.|At least 500 MB is required. Free some disk space and try again." 722=%1：磁碟的空間不足臨時資料|最少需要%2 MB的空间。請釋放一些磁碟空間，然後再試一次。 # e.g. "Your system should be upgraded to the latest Service Pack for Windows Vista, which is SP2 at the moment. You can use Windows Update or download a standalone Service Pack package (download link can be found in Help).|Note that it is suggested to change back to the original language (English) or another Internal language to make sure the Service Pack will be installed successfully. 723=您的系统將被更新最新%1的Service Pack，現在為SP%2。您可以使用Windows Update或下載独立Service Pack安裝包 (下載連接在幫助文件中)。|請注意，建議您先更改顯示語言設為原始語言 (%3) 或其它内部語言，確認Service Pack成功安裝。 # a checkbox message in a window with the above message 724=不要再顯示此信息。 # e.g. "A language with English name "Spanish" is already loaded.|This file will be skipped from processing." 725=已加載英語名稱為 “%1” 的語言。|此文件在處理過程中將被跳過。 # e.g. "All language files exported successfully to：|C：\Program Files\Vistalizator\Languages" 726=所有語言文件已輸出至：|%1 727=Note that MUI languages installed in Express mode are not kept up to date by Windows. See Help for details how to update them by Vistalizator itself.|You are encouraged to try Internal installation first. 

Hello All, I want to emphasis the request to test as: 1. The installer was fully re-written almost nothing remained from the original one. 2. We now provide both 32bit and 64bit binaries, so far only 32bit binaries were provided. 3. All userspace binaries are compiled using mingw-w64 compiler, this is also a change from previous releases. 4. The tap-windows driver has its own installer which is embedded as-is within the openvpn installer. Any input will be much appreciated! Alon. On Wed, May 16, 2012 at 3:45 PM, Samuli Seppänen <sa...@op...> wrote: > Forgot to mention... If you're interested in testing just the TAP-driver > installer, it's available here: > > <http://build.openvpn.net/downloads/snapshots/tap-windows-9.9.0_master.exe> > > Best regards, > > Samuli > > >> Hi all, >> >> Here are the first fully-functional Windows installers built (by me) >> with Alon's new cross-compilation environment (a.k.a. "generic" >> buildsystem): >> >> <http://build.openvpn.net/downloads/snapshots/openvpn-install-2.3_master-I000_master-i686.exe> >> <http://build.openvpn.net/downloads/snapshots/openvpn-install-2.3_master-I000_master-x86_64.exe> >> >> The installers and executables and libraries in them have been signed >> with a self-signed test certificate. This means that Windows Vista/7 >> 64-bit will refuse to install the (self-signed) TAP-drivers, unless this >> CA certificate is in the system keystore: >> >> <http://build.openvpn.net/downloads/openvpntestca-cert.cer> >> >> This certificate can be imported using Microsoft management console >> (mmc.exe): >> >> - Add  the "Certificates" snap-in >> - Go to "Trusted root certificates" >> - Right-click "Certificates" >> - Select "All tasks" -> "Import" >> >> After this you can run the OpenVPN installer and it should just work. A >> version of OpenVPN signed with paid-for certificate is coming soonish. >> That one will work on any supported Windows version without jumping >> through these hoops. >> >> Have fun (and please report back any issues you find), > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/05/12 16:39, Alon Bar-Lev wrote: [...snip...] > > I am for announcing the removal have the time for all plugins > authors which may use this feature to modify their code. There is > enough time to do so, we are talking about ~5 months. Just to clarify, as Alon and I have had an IRC discussion today. We've agreed that we will keep this code snippet enabled by default in v2.3. In v2.4 we will flip it to disabled by default. And in v2.5, it will go away. The reason is also that code from James have arrived into the v2.3 code base which provides pretty much the same information as 'tls_digest_%d' does, using a new feature: --x509-track See commit 9356bae859938c and commit 5cdb5e0111df7b3d for more information about that. > I am not sure that anyone knows this one even exists as was unique > to David's need. So most probably only the eurephia should be > modified. I will take care of modifying eurephia and it's documentation. > Samuli, I think it is simple enough... in the 2.3_alpha2 > announcement, announce that the tls_digest_* environment is > obsolete and until 2.3 release all plugins authors must modify > their plugins to use the V3 interface to extract this information > (if needed). Plug-ins can use the plug-in API v3 indeed. Scripts however need to use the new --x509-track feature instead and be rewritten to extract the information from a different environment variable. Both are new features in the coming OpenVPN v2.3. So we do need a transition period before pulling this feature. So, leave it as is in v2.3, flip to disabled by default in v2.4 (--disable-eurephia changes to --enable-eurephia) and remove it completely in v2.5. And add clear and informative release notes for all of these versions. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+zzmkACgkQDC186MBRfrqBlACggTOMyC8L75Ctpbaxhl3KQ7bu yCEAnjFI60k7C0In0Bjp98Zo+WipYSlB =BMvf -----END PGP SIGNATURE----- 

On Wed, May 16, 2012 at 5:30 PM, David Sommerseth <ope...@to...> wrote: >> But now that you describe you can do this using the plugin API, >> why not modify the plugin to perform this and just remove this? > > I don't know if I'm the only user of this information or not.  If I'm > not, then we will break things for others as well.  That I don't like, > especially when the current implementation covers both plug-ins and > scripts. Well, this is exactly my point in rejecting these kind of merges into the code, examples: Android case, Windows privilege separation case. A great example! There are no temporary merges, only maintenance costs and code complexity. This why features should be maintained outside of tree until properly merged with proper design. This process it is not unique to this project. I am for announcing the removal have the time for all plugins authors which may use this feature to modify their code. There is enough time to do so, we are talking about ~5 months. I am not sure that anyone knows this one even exists as was unique to David's need. So most probably only the eurephia should be modified. Samuli, I think it is simple enough... in the 2.3_alpha2 announcement, announce that the tls_digest_* environment is obsolete and until 2.3 release all plugins authors must modify their plugins to use the V3 interface to extract this information (if needed). Alon. 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/05/12 14:38, Alon Bar-Lev wrote: > On Wed, May 16, 2012 at 3:33 PM, David Sommerseth > <ope...@to...> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 16/05/12 14:03, Alon Bar-Lev wrote: [...snip...] >>> But if I get this right, a new configuration option is needed, >>> not compile time directive, something like: >>> >>> --setenv-data [-]<data>, ... >>> >>> data :: cert-digest-sha1 >>> >>> This way, only users which require this functionality may >>> enable it and perform hash of the chain. No stability issues in >>> this mode. >> >> I think when James is concerned about stability issues, it is >> more the situation of the code changing than growing the >> environment list too long. However, a too big environment list >> may cause stability issues as well (overflow situations, etc). >> So you have a good argument as well. >> >> (In my case with the eurephia support, I added the #ifdef to make >> it more likely that it would be accepted by James.) >> >>> In this scheme we can add more data types if required, and >>> assign data types for existing functionality, allowing to >>> disable using "-", example is cert-serial or cert-subject or >>> certh-depth. >>> >>> What do you think? >> >> I like this idea. However, the plug-in v3 API is probably >> solving some of these things as well, as that provides access to >> the whole X509 structure. That doesn't solve it for scripts, >> though, but for plug-ins that will provide all the information >> ever needed directly. > > Oh... so if the 2.3 can provide this information to your plugin, > can we remove this entirely? I would prefer not to change this at the current point. The eurephia plug-in needs to be updated before we can do such a move. And even though eurephia is the only known user of this information currently; We don't know if there are others who have began using this information already which we don't know about. So we might break things, especially if other users are scripts. >> But if I see it from a security perspective, reducing the amount >> of environment variables and only providing the information >> requested for makes a lot of sense - and this would affect both >> plug-ins and scripts too. > > But plugins should not communicate via environment... I was > confused, as I concluded that if you set the environment the target > consumer is a script. Please, look carefully at the plug-in API. It provides an extra array pointer, which contains the environment variables. OPENVPN_PLUGIN_DEF int OPENVPN_PLUGIN_FUNC(openvpn_plugin_func_v1) (openvpn_plugin_handle_t handle, const int type, const char *argv[], const char *envp[]); OPENVPN_PLUGIN_DEF int OPENVPN_PLUGIN_FUNC(openvpn_plugin_func_v2) (openvpn_plugin_handle_t handle, const int type, const char *argv[], const char *envp[], void *per_client_context, struct openvpn_plugin_string_list **return_list); OPENVPN_PLUGIN_DEF int OPENVPN_PLUGIN_FUNC(openvpn_plugin_func_v3) (const int version, struct openvpn_plugin_args_func_in const *arguments, struct openvpn_plugin_args_func_return *retptr); struct openvpn_plugin_args_func_in { const int type; const char ** const argv; const char ** const envp; ... For C based plug-ins, you don't use the "traditional" getenv() function, to grab this info. You need to extract this information from the envp pointers. >> What I'm actually thinking, in regards to backwards >> compatibility, is that there is a default environment variable >> list which consists of the variables we provide today. If >> --setenv-data is used, this list is reset. So if you use >> --setenv-data, you need to also include those variables which was >> there before - if you really need them. It will naturally >> require more thinking when this is being configured by the >> users. > > I thought of having the default as enabled and put '-' before > element to remove... -* can remove all like Gentoo USE flags :) Well, I believe most average admins are lazy by nature. And to make them use a more securer approach, you need to force them to do it. Even though '-*' is quite elegant, it won't last long before someone asks for '+*' to enable all - with the reason "It's so many variables, I'll just take them all and don't think about it any more". > But now that you describe you can do this using the plugin API, > why not modify the plugin to perform this and just remove this? I don't know if I'm the only user of this information or not. If I'm not, then we will break things for others as well. That I don't like, especially when the current implementation covers both plug-ins and scripts. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+zuhsACgkQDC186MBRfrpxRgCgmuDjQjL03g8drXkACuk+qGiZ jGQAmwX6EWh71ci2DOMALovlC3hoH5M0 =ocVF -----END PGP SIGNATURE----- 

Forgot to mention... If you're interested in testing just the TAP-driver installer, it's available here: <http://build.openvpn.net/downloads/snapshots/tap-windows-9.9.0_master.exe> Best regards, Samuli > Hi all, > > Here are the first fully-functional Windows installers built (by me) > with Alon's new cross-compilation environment (a.k.a. "generic" > buildsystem): > > <http://build.openvpn.net/downloads/snapshots/openvpn-install-2.3_master-I000_master-i686.exe> > <http://build.openvpn.net/downloads/snapshots/openvpn-install-2.3_master-I000_master-x86_64.exe> > > The installers and executables and libraries in them have been signed > with a self-signed test certificate. This means that Windows Vista/7 > 64-bit will refuse to install the (self-signed) TAP-drivers, unless this > CA certificate is in the system keystore: > > <http://build.openvpn.net/downloads/openvpntestca-cert.cer> > > This certificate can be imported using Microsoft management console > (mmc.exe): > > - Add the "Certificates" snap-in > - Go to "Trusted root certificates" > - Right-click "Certificates" > - Select "All tasks" -> "Import" > > After this you can run the OpenVPN installer and it should just work. A > version of OpenVPN signed with paid-for certificate is coming soonish. > That one will work on any supported Windows version without jumping > through these hoops. > > Have fun (and please report back any issues you find), 

On Wed, May 16, 2012 at 3:33 PM, David Sommerseth <ope...@to...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 16/05/12 14:03, Alon Bar-Lev wrote: > [...snip...] >> But if I get this right, a new configuration option is needed, not >> compile time directive, something like: >> >> --setenv-data [-]<data>, ... >> >> data :: cert-digest-sha1 >> >> This way, only users which require this functionality may enable >> it and perform hash of the chain. No stability issues in this >> mode. > > I think when James is concerned about stability issues, it is more the > situation of the code changing than growing the environment list too > long.  However, a too big environment list may cause stability issues > as well (overflow situations, etc).  So you have a good argument as well. > > (In my case with the eurephia support, I added the #ifdef to make it > more likely that it would be accepted by James.) > >> In this scheme we can add more data types if required, and assign >> data types for existing functionality, allowing to disable using >> "-", example is cert-serial or cert-subject or certh-depth. >> >> What do you think? > > I like this idea.  However, the plug-in v3 API is probably solving > some of these things as well, as that provides access to the whole > X509 structure.  That doesn't solve it for scripts, though, but for > plug-ins that will provide all the information ever needed directly. Oh... so if the 2.3 can provide this information to your plugin, can we remove this entirely? > But if I see it from a security perspective, reducing the amount of > environment variables and only providing the information requested for > makes a lot of sense - and this would affect both plug-ins and scripts > too. But plugins should not communicate via environment... I was confused, as I concluded that if you set the environment the target consumer is a script. >  So from a 'need to know' basis, I like this approach.  But if we > add a revolution here, it's probably better suited for a v3.0 scope. > However, if we provide a way of backwards compatibility, we can scope > it for v2.x. Oh... I think that if you can do this with the v3 API we can simply remove the code. > What I'm actually thinking, in regards to backwards compatibility, is > that there is a default environment variable list which consists of > the variables we provide today.  If --setenv-data is used, this list > is reset.  So if you use --setenv-data, you need to also include those > variables which was there before - if you really need them.  It will > naturally require more thinking when this is being configured by the > users. I thought of having the default as enabled and put '-' before element to remove... -* can remove all like Gentoo USE flags :) But now that you describe you can do this using the plugin API, why not modify the plugin to perform this and just remove this? Alon. 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/05/12 14:03, Alon Bar-Lev wrote: [...snip...] > But if I get this right, a new configuration option is needed, not > compile time directive, something like: > > --setenv-data [-]<data>, ... > > data :: cert-digest-sha1 > > This way, only users which require this functionality may enable > it and perform hash of the chain. No stability issues in this > mode. I think when James is concerned about stability issues, it is more the situation of the code changing than growing the environment list too long. However, a too big environment list may cause stability issues as well (overflow situations, etc). So you have a good argument as well. (In my case with the eurephia support, I added the #ifdef to make it more likely that it would be accepted by James.) > In this scheme we can add more data types if required, and assign > data types for existing functionality, allowing to disable using > "-", example is cert-serial or cert-subject or certh-depth. > > What do you think? I like this idea. However, the plug-in v3 API is probably solving some of these things as well, as that provides access to the whole X509 structure. That doesn't solve it for scripts, though, but for plug-ins that will provide all the information ever needed directly. But if I see it from a security perspective, reducing the amount of environment variables and only providing the information requested for makes a lot of sense - and this would affect both plug-ins and scripts too. So from a 'need to know' basis, I like this approach. But if we add a revolution here, it's probably better suited for a v3.0 scope. However, if we provide a way of backwards compatibility, we can scope it for v2.x. What I'm actually thinking, in regards to backwards compatibility, is that there is a default environment variable list which consists of the variables we provide today. If --setenv-data is used, this list is reset. So if you use --setenv-data, you need to also include those variables which was there before - if you really need them. It will naturally require more thinking when this is being configured by the users. Of course, it's possible to add a keyword 'default' to re-enable the default list as well. But that will only allow mindless configurations, where people just add this keyword instead of really evaluating the variables they need (We already have a lot of mindless configuration questions on IRC, haven't checked the forum carefully enough; but we don't need more of these requests). And if they end up listing all, something else is most likely wrong in the config as well. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+znpMACgkQDC186MBRfrpZ2ACeLpcDSPtUodxgh3QKYG0rcPFs h2kAn0AnO8LYCTTyiEZl/5h+7I7TaUMq =D6NW -----END PGP SIGNATURE----- 

On Wed, May 16, 2012 at 2:37 PM, David Sommerseth <ope...@to...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 16/05/12 12:55, Alon Bar-Lev wrote: >> On Wed, May 16, 2012 at 1:46 PM, David Sommerseth >> <ope...@to...> wrote: >>> On 16/05/12 12:37, Alon Bar-Lev wrote: >>>> On Wed, May 16, 2012 at 1:27 PM, David Sommerseth >>>> <ope...@to...> wrote: >>>>> On 16/05/12 09:17, Alon Bar-Lev wrote: >>>>>> Hello David, > [...snip...] >>>>>> Can you please explain what this plugin is and why just >>>>>> remove the conditional? >>>>> >>>>> You can find more info about the plug-in here: >>>>> http://www.eurephia.net/ >>>>> >>>>> Basically, it's a username/password authentication plug-in >>>>> which also matches a user account up against a certificate >>>>> too (plus some extra features too as well).  The >>>>> 'tls_digest_%d' environment variable is used to get better >>>>> data when matching certificates information against the >>>>> database. > [...snip...] >> >> hmmm... why not to digest only end certificate? this what you >> actually need right? > > For the most common setup where you only have a single CA and the > client cert, the tls_digest_0 env. variable is the important factor. > > But some users might do some tricks with certificate chains, using CA > and sub-CA(s), which a plug-in/script then can better validate if it > has all the levels. > > For example, the firewall profiles for each user can be different > based on which kind of device you're connecting from (workstation, > laptop, tablet, etc) - and each group of devices can have certificates > issued by different sub-CAs.  But the end-user have only one > username/password to care about (the certificates/keys are distributed > by the enterprise in their preferred way to their devices), and based > on the certificate chain, the network access changes. > > This way, if one sub-CA is removed/disabled from the eurephia > database, you can easily remove access from a complete group.  Maybe > that's something you only want to do temporarily, so issuing a CRL for > a sub-CA would be too extreme.  Such setups are more interesting for > enterprises, though.  But key point is to have a fine-grained control > of all the VPN accesses. > > The thoughts behind eurephia has been to provide a runtime modularity > and being as flexible as possible; not locking the users towards only > a limited kind of setups. > > Granted, all the certificate-chain support isn't implemented in > eurephia yet, but it's on the TODO list. OK, I am starting to understand. Had I needed to implement this I would have done this differently... As PKI already establish trust, usually all you need is the subject name and/or issuer name to differentiate between certificates. But if I get this right, a new configuration option is needed, not compile time directive, something like: --setenv-data [-]<data>, ... data :: cert-digest-sha1 This way, only users which require this functionality may enable it and perform hash of the chain. No stability issues in this mode. In this scheme we can add more data types if required, and assign data types for existing functionality, allowing to disable using "-", example is cert-serial or cert-subject or certh-depth. What do you think? Alon. 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/05/12 12:55, Alon Bar-Lev wrote: > On Wed, May 16, 2012 at 1:46 PM, David Sommerseth > <ope...@to...> wrote: >> On 16/05/12 12:37, Alon Bar-Lev wrote: >>> On Wed, May 16, 2012 at 1:27 PM, David Sommerseth >>> <ope...@to...> wrote: >>>> On 16/05/12 09:17, Alon Bar-Lev wrote: >>>>> Hello David, [...snip...] >>>>> Can you please explain what this plugin is and why just >>>>> remove the conditional? >>>> >>>> You can find more info about the plug-in here: >>>> http://www.eurephia.net/ >>>> >>>> Basically, it's a username/password authentication plug-in >>>> which also matches a user account up against a certificate >>>> too (plus some extra features too as well). The >>>> 'tls_digest_%d' environment variable is used to get better >>>> data when matching certificates information against the >>>> database. [...snip...] > > hmmm... why not to digest only end certificate? this what you > actually need right? For the most common setup where you only have a single CA and the client cert, the tls_digest_0 env. variable is the important factor. But some users might do some tricks with certificate chains, using CA and sub-CA(s), which a plug-in/script then can better validate if it has all the levels. For example, the firewall profiles for each user can be different based on which kind of device you're connecting from (workstation, laptop, tablet, etc) - and each group of devices can have certificates issued by different sub-CAs. But the end-user have only one username/password to care about (the certificates/keys are distributed by the enterprise in their preferred way to their devices), and based on the certificate chain, the network access changes. This way, if one sub-CA is removed/disabled from the eurephia database, you can easily remove access from a complete group. Maybe that's something you only want to do temporarily, so issuing a CRL for a sub-CA would be too extreme. Such setups are more interesting for enterprises, though. But key point is to have a fine-grained control of all the VPN accesses. The thoughts behind eurephia has been to provide a runtime modularity and being as flexible as possible; not locking the users towards only a limited kind of setups. Granted, all the certificate-chain support isn't implemented in eurephia yet, but it's on the TODO list. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+zkWQACgkQDC186MBRfrr2iQCgjkAJX4l0KNkrZjcChAws6+Dc 5mAAn0Wki7i0ZiMcsNL6W6npWtw7kqW5 =Gomp -----END PGP SIGNATURE----- 

Hi all, Here are the first fully-functional Windows installers built (by me) with Alon's new cross-compilation environment (a.k.a. "generic" buildsystem): <http://build.openvpn.net/downloads/snapshots/openvpn-install-2.3_master-I000_master-i686.exe> <http://build.openvpn.net/downloads/snapshots/openvpn-install-2.3_master-I000_master-x86_64.exe> The installers and executables and libraries in them have been signed with a self-signed test certificate. This means that Windows Vista/7 64-bit will refuse to install the (self-signed) TAP-drivers, unless this CA certificate is in the system keystore: <http://build.openvpn.net/downloads/openvpntestca-cert.cer> This certificate can be imported using Microsoft management console (mmc.exe): - Add the "Certificates" snap-in - Go to "Trusted root certificates" - Right-click "Certificates" - Select "All tasks" -> "Import" After this you can run the OpenVPN installer and it should just work. A version of OpenVPN signed with paid-for certificate is coming soonish. That one will work on any supported Windows version without jumping through these hoops. Have fun (and please report back any issues you find), -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

On Wed, May 16, 2012 at 1:46 PM, David Sommerseth <ope...@to...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 16/05/12 12:37, Alon Bar-Lev wrote: >> On Wed, May 16, 2012 at 1:27 PM, David Sommerseth >> <ope...@to...> wrote: >>> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 16/05/12 09:17, Alon Bar-Lev wrote: >>>> Hello David, >>>> >>>> I guess this is yours: --- *  Additions for eurephia plugin >>>> done by: *         David Sommerseth >>>> <da...@us...> Copyright (C) 2009 --- >>>> >>>> Looking at the code the eurephia plugin only do the following: >>>> --- #ifdef ENABLE_PLUGIN_EUREPHIA /* export X509 cert SHA1 >>>> fingerprint */ { unsigned char *sha1_hash = >>>> x509_get_sha1_hash(peer_cert, &gc); >>>> >>>> openvpn_snprintf (envname, sizeof(envname), "tls_digest_%d", >>>> cert_depth); setenv_str (es, envname, format_hex_ex(sha1_hash, >>>> SHA_DIGEST_LENGTH, 0, 1, ":", &gc)); } #endif --- >>>> >>>> Can you please explain what this plugin is and why just remove >>>> the conditional? >>> >>> You can find more info about the plug-in here: >>> http://www.eurephia.net/ >>> >>> Basically, it's a username/password authentication plug-in which >>> also matches a user account up against a certificate too (plus >>> some extra features too as well).  The 'tls_digest_%d' >>> environment variable is used to get better data when matching >>> certificates information against the database. >>> >>> I've been thinking that this whole #ifdef could go away in v2.4. >>> It was a requirement from James to make this optional which is >>> the reason it is how it is.  He wanted to be sure it can be >>> disabled if there were stability concerns.  As this has been >>> enabled by default in 2.2 and will be in 2.3, I thought 2.4 would >>> be a reasonable time to confirm the stability. >>> >>> The [eurephia] string can also be removed then from options.c >>> too; and I'll make sure the eurephia docs states that v2.4 >>> contains the support even though not explicitly announced. >> >> Thanks. I don't see any reason why not to remove the #ifdef for >> 2.3... it is default enabled anyway, so it is not like people >> should explicit enable this and get lower stability. > > It was actually the other way around.  If people had stability issues, > which might be related to environment tables growing too big (or > somewhat related issues), this feature could be disabled to see if > that helped it.  Doing it like it is implemented made James happy, so > I didn't argue about it. hmmm... why not to digest only end certificate? this what you actually need right? > >> Anyway, if the need of the digest is valid then it is not specific >> to this plugin. > > AFAIK, eurephia is the only plug-in depending on this feature, and it > this feature arrived first in v2.2.  So it was kind of to have a > clearer reference to what this feature is about.  But I see that this > information can be useful for other plug-ins/scripts as well. The whole point of plugin is that no change in base... conditionals should be based on functionality. Thanks, Alon 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/05/12 12:37, Alon Bar-Lev wrote: > On Wed, May 16, 2012 at 1:27 PM, David Sommerseth > <ope...@to...> wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 16/05/12 09:17, Alon Bar-Lev wrote: >>> Hello David, >>> >>> I guess this is yours: --- * Additions for eurephia plugin >>> done by: * David Sommerseth >>> <da...@us...> Copyright (C) 2009 --- >>> >>> Looking at the code the eurephia plugin only do the following: >>> --- #ifdef ENABLE_PLUGIN_EUREPHIA /* export X509 cert SHA1 >>> fingerprint */ { unsigned char *sha1_hash = >>> x509_get_sha1_hash(peer_cert, &gc); >>> >>> openvpn_snprintf (envname, sizeof(envname), "tls_digest_%d", >>> cert_depth); setenv_str (es, envname, format_hex_ex(sha1_hash, >>> SHA_DIGEST_LENGTH, 0, 1, ":", &gc)); } #endif --- >>> >>> Can you please explain what this plugin is and why just remove >>> the conditional? >> >> You can find more info about the plug-in here: >> http://www.eurephia.net/ >> >> Basically, it's a username/password authentication plug-in which >> also matches a user account up against a certificate too (plus >> some extra features too as well). The 'tls_digest_%d' >> environment variable is used to get better data when matching >> certificates information against the database. >> >> I've been thinking that this whole #ifdef could go away in v2.4. >> It was a requirement from James to make this optional which is >> the reason it is how it is. He wanted to be sure it can be >> disabled if there were stability concerns. As this has been >> enabled by default in 2.2 and will be in 2.3, I thought 2.4 would >> be a reasonable time to confirm the stability. >> >> The [eurephia] string can also be removed then from options.c >> too; and I'll make sure the eurephia docs states that v2.4 >> contains the support even though not explicitly announced. > > Thanks. I don't see any reason why not to remove the #ifdef for > 2.3... it is default enabled anyway, so it is not like people > should explicit enable this and get lower stability. It was actually the other way around. If people had stability issues, which might be related to environment tables growing too big (or somewhat related issues), this feature could be disabled to see if that helped it. Doing it like it is implemented made James happy, so I didn't argue about it. > Anyway, if the need of the digest is valid then it is not specific > to this plugin. AFAIK, eurephia is the only plug-in depending on this feature, and it this feature arrived first in v2.2. So it was kind of to have a clearer reference to what this feature is about. But I see that this information can be useful for other plug-ins/scripts as well. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+zhW0ACgkQDC186MBRfrr5hQCfepddgwecRP0a8V+hJaM5n+Y9 gK8An3mlCMUAwjl5AlHojMOah3w0rGAd =y4TQ -----END PGP SIGNATURE-----